建议一：在数据库服务器过滤数据，而不是在应用程序上。
在通常情况下，若是在服务器上过滤数据，其效率始终会高于将数据发送到应用程序，然乎在应用程序上对数据进行过滤。如当应用程序利用 Select * FROM 语句，要求数据库服务器将所有列数据返回给应用程序，不论应用程序是否已绑定这些列以在程序变量中使用。但是，在应用程序中，往往不会把所有的列都显示出来。根据笔者的数据库开发经验，除非应用程序是根据客户需求进行自定义，否则的话，像那种套装软件，其为了能够满足不同企业的需求，往往会在数据库表中设置比较多的字段。故这返回给应用程序的字段，若其利用率能够达到60%已经算高了。这就导致从数据库服务器端传递给应用程序的数据，很多都是无用的。故在查询语句中，按名称只选择必要的列可避免不必要的网络流量。
同时，这么设计还可以带来另外一个好处。如可以使得应用程序在表定义时更加的可靠，因为新添加的列不返回给客户端应用程序。在 SQLServer服务器中，支持在服务器上过滤数据，以便给应用程序返回最小的所需数据。使用这个功能可以使得服务器与应用程序之间高耗费的网络流量减到最小。
若在应用程序中带有用户自定义报表功能的话，这个建议就会非常有用。因为报表自定义系统，信息化管理软件的用户就可以利用这个平台，根据自身企业的需要，对报表进行自定义，选择自己所需要的字段内容。此时，应用程序在生成报表的Select语句中，就要根据用户自定义显示的内容，从数据库中查询相关的列。而不需要把对应表中所有列都查询出来。无疑，这可以在很大程度上提高应用程序的性能。
建议二：应用程序应立即从数据库结果集中提取所有的行。
当应用程序采用开放式数据库连接技术连接SQLServer数据库时，在执行查询前设置的语句选项决定应用程序如何从服务器请求结果集。默认情况下，数据库以最有效的方式发送结果集。即大部分情况下，数据库都假定应用程序立即才能够数据库结果集中提取所有的行。
对于这一点，很多应用程序开发人员存在一个误解。他们错误的认为，请求默认结果集只按应用程序逻辑或者用户商业逻辑提取结果集中所需要的行，这会节省网络与应用程序的开销。其实，这是错误的。因为如果应用程序不马上从数据库结果集中提取所有的行的话，会阻碍其他应用程序客户端与服务器之间的连接，而且还会阻塞同一个事务中的其他工作。更严重的是，未从结果集中提取的行会导致数据库服务器上相关的表中加锁，从而有可能阻碍其他用户对于数据的更新。当信息化管理软件的用户越多，这个负面作用会越来越明显。故除非有其他的考虑，否则的话，应用程序在设计时，要立即从数据库默认结果集中提取所有的行。
建议三：使用游标技术来改善大表数据的查询。
不过，在实际工作中，仍然有一些应用程序无法一次性从数据库服务器中提取所有的结果行。如应用程序查询大表并且允许用户指定选择条件，此时，有可能数据库服务器会返回几万行，甚至达到上百万行。若让应用程序缓冲这么多的数据，那么应用程序的缓冲空间很快会被消耗殆尽;同时也增加了额外的网络流量。而终端用户，可能并不需要看到这么多的行。如在实际工作中，终端用户往往有一个不好的习惯。他们第一次查询数据时，往往会不选择任何查询条件查询数据。当他们看到查询出来的数据比较多时，才会尝试着去输入一些限制条件，如利用信息类别或者部分名字实现模糊查询等等。在这种情况下，应用程序提取和缓冲上百万条的记录，而用户最终仍然会丢弃这些行。这无疑会浪费很多的时间和资源。
可是如果不马上提取所有的结果行，会产生建议二所描述的不利结果。那该如何是好呢?SQLServer数据库为了解决这个问题，提出了一个游标技术。在谈这个游标技术之前，笔者先谈一个具体的例子，以帮助大家对于游标有一个感性的认识。
在一些成熟的应用系统中，当用户查询数据时，如果数据量比较多，则在应用程序的窗口中，显示的是一个屏幕的数据。也就是说，应用程序并不立即从数据库中提取所有的行;而只提取一屏幕的行。当用户发现自己所需要的数据并不在这个屏幕中，则可以点击“下一屏”等类似的按钮，让应用程序窗口显示其他的内容。用户每点击一次，应用程序就从数据库服务器中提取一屏幕的行。此时，因为用了游标技术，所以数据库管理员不用担心未提取的数据行产生的锁冲突问题。
那么游标技术到底可以带来哪些收益呢？且听笔者一一道来。
首先，数据库提供服务器游标允许应用程序从任意大的结果集中提取行子集或者行快，如上面例子中的一屏幕行。如果用户想看到同一结果集中的其他数据，服务器游标允许应用程序从数据库结果集中提取任何其他的行块，如结果集后面的N行、前面的N行、或者中间某行后面的N行等等。数据库服务器只根据需要执行每个块提取请求。最重要的是，数据库服务器通常不会在服务器游标上的块提取之间对表或者表中的行加锁。如此的话，即使应用程序未从数据库服务器中提取所有的结果，那么也不影响其它用户对这数据表结果的修改。
