如何使用高效数据检索优化应用程序性能

SQL 语言的功能之一是能够在服务器上筛选数据，以便只给客户端返回最少的所需数据。使用这些功能可使服务器与客户端间的高耗费的网络流量减到最小。这意味着必须使 WHERE 子句的限制性足够强，从而使其只检索应用程序所需的数据。

若是在服务器上筛选数据，则效率始终会高于将数据发送到客户端、然后在应用程序中筛选数据。这种情况也适用于从服务器请求的列。发出 SELECT * FROM... 语句的应用程序要求服务器将所有列数据返回给客户端，不论客户端应用程序是否已绑定这些列以在程序变量中使用。按名称只选择必要的列可避免不必要的网络流量。这也使应用程序在表定义更改时更可靠，因为新添加的列不返回给客户端应用程序。

性能还取决于应用程序如何从服务器请求结果集。在使用开放式数据库连接 (ODBC) 的应用程序中，在执行查询前设置的语句选项决定应用程序如何从服务器请求结果集。当保留语句选项的默认值时，Microsoft® SQL Server™ 2000 以最有效的方式发送结果集。

SQL Server 假定应用程序立即从默认结果集中提取所有的行。因此，该应用程序必须缓冲那些不立即使用但以后可能需要的行。这种缓冲需求决定了（通过使用 Transact-SQL）仅指定所需的数据尤其重要。

请求默认结果集并只按应用程序逻辑或应用程序用户的需要提取行这一做法看起来很节省，但却是假节省。未从默认结果集中提取的行会阻碍与服务器的连接，并阻塞同一事务中的其它工作。另外，未从默认结果集中提取的行会导致 SQL Server 在服务器上控制锁，从而有可能防碍其他用户更新。在小规模测试中可能不会出现这种并发问题，但是以后部署应用程序时则会出现该问题。因此，应立即从默认结果集中提取所有的行。

有些应用程序无法缓冲它们从服务器请求的所有数据。例如，如果应用程序查询大表并允许用户指定选择条件，则可能不返回任何行或返回上百万行。而用户不大可能想查看上百万行。相反，用户更有可能缩小选择条件重新执行查询。在此情况下，提取和缓冲上百万行，而用户最终丢弃这些行，无疑是浪费时间和资源。

对于这些应用程序，SQL Server 提供服务器游标以允许应用程序从任意大的结果集中提取小的行子集或行块。如果用户想看到同一结果集内的其它记录，服务器游标允许应用程序从结果集中提取任何其它行块，包括结果集内后面的 n 行、前面的 n 行或从某行开始的 n 行。SQL Server 只根据需要执行每个块提取请求，而且 SQL Server 通常不在服务器游标上的块提取之间控制锁。

服务器游标还允许应用程序对提取的行执行定位更新或删除，而无须确定行的源表和主键。如果行数据从提取到请求更新的这段期间内更改，SQL Server 会检测出这个问题并防止丢失更新。

但是，服务器游标的功能需要一定的代价。如果给定查询的所有结果都要在应用程序中使用，则服务器游标总是比默认结果集消费高。默认结果集始终只需要在客户端和服务器间往返一次，而每次用服务器游标调用提取行块操作便导致一次往返。此外，服务器游标消耗服务器上的资源，对某些类型的游标可以使用的 SELECT 语句也有限制。例如，KEYSET 游标被限制为只能使用带唯一索引的表，而 KEYSET 和 STATIC 游标大量使用服务器上的临时存储。由于这些原因，只有应用程序需要服务器游标功能时才使用这些服务器游标。如果某个任务通过主键请求单个行，则使用默认结果集。如果另外一个任务需要大得无法预料的结果集或可更新的结果集，则使用服务器游标提取大小适中的块（例如一次提取一屏行）。另外，只要可能就应对自动提取使用快速只进游标。可以使用这些游标只在客户端和服务器之间往返一次而检索出小结果集，这与使用默认结果集相似。