SQL Server 2000优化SELECT语句方法

核心提示： 这个扫描统计告诉我们扫描执行的数量，逻辑读显示的是从缓存中读出来的页面的数量，SQL Server 2000优化SELECT语句方法(2)，物理读显示的是从磁盘中读的页面的数量，Read-ahead 读显示了放置在缓存中用于将来读操作的页面数量，不关心数据的缓存和有效的read-ahead

这个扫描统计告诉我们扫描执行的数量，逻辑读显示的是从缓存中读出来的页面的数量，物理读显示的是从磁盘中读的页面的数量，Read-ahead 读显示了放置在缓存中用于将来读操作的页面数量。

此外，我们执行一个系统存储过程获得表大小的统计信息以供我们分析：

sp_spaceused employees
Results:
name rows reserved data index_size unused
-------------- -------- --------- -------
Employees 2977 2008KB 1504KB 448KB 56KB

通过看这些信息我们能得到些什么呢？

这个查询没有扫描整个表，在表中的数据量超过1.5M字节，而仅仅执行了53个逻辑I/O操作就得到了结果。这表明该查询发现了一个可用来计算结果的索引，并且扫描索引比扫描所有数据页花费更少的I/O操作。

索引页几乎全部放在数据缓存中，所以物理读的值是零。这是因为我们之前不久是在employees表上执行了其他查询，此时表和它的索引已经被缓存。你的查询开销可能有不同。

Microsoft报告没有read-ahead（预读）活动。在这种情况下，数据和索引页已经被缓存起来了。当对一个很大的表作表扫描时，read-ahead可能会半路插入进来，并且在你的查询用到它们之前缓存起所需的页。当SQL Server确定你的事务是顺序读取数据库页并且认为它能预测到你下一步将用到的页面时，Real-ahead会自动打开。实际上一个独立的SQL Server连接在你的进程之前已开始运行并为它缓存数据页。（配置和优化read-ahead 参数已超出这篇文章的讨论范围。

在这个例子中，该查询已经尽可能有效率地执行了，不必进一步优化。

SET STATISTICS TIME

一个事务的实耗时间是一个不稳定的测量，因为这些时间与在服务器上其他用户的活动有关。然而，相比那些对你的用户没有任何意义的数据页数字，它提供了一些实际的测量。他们关心等待查询返回的时间消耗，不关心数据的缓存和有效的read-ahead。SET STATISTICS TIME ON命令报告下面的查询的实际占用时间和CPU使用情况。执行SET STATISTICS TIME OFF禁止这个选项。