教你如何看懂SQL Server查询计划(6)

当 AUTO_UPDATE_STATISTICS 数据库选项设置为 ON（默认值）时，查询优化器会在表中的数据发生变化时自动定期更新这些统计信息。每当查询执行计划中使用的统计信息没有通过针对当前统计信息的测试时就会启动统计信息更新。采样是在各个数据页上随机进行的，取自表或统计信息所需列的最小非聚集索引。从磁盘读取一个数据页后，该数据页上的所有行都被用来更新统计信息。常规情况是：在大约有 20% 的数据行发生变化时更新统计信息。但是，查询优化器始终确保采样的行数尽量少。对于小于 8 MB 的表，则始终进行完整扫描来收集统计信息。

采样数据（而不是分析所有数据）可以将统计信息自动更新的开销降至最低。在某些情况下，统计采样无法获得表中数据的精确特征。可以使用 UPDATE STATISTICS 语句的 SAMPLE 子句和 FULLSCAN 子句，控制按逐个表的方式手动更新统计信息时采样的数据量。FULLSCAN 子句指定扫描表中的所有数据来收集统计信息，而 SAMPLE 子句用来指定采样的行数百分比或采样的行数

在 SQL Server 2005 中，数据库选项 AUTO_UPDATE_STATISTICS_ASYNC 提供了统计信息异步更新功能。当此选项设置为 ON 时，查询不等待统计信息更新，即可进行编译。而过期的统计信息置于队列中，由后台进程中的工作线程来更新。查询和任何其他并发查询都通过使用现有的过期统计信息立即编译。由于不存在等待更新后的统计信息的延迟，因此查询响应时间可预测；但是过期的统计信息可能导致查询优化器选择低效的查询计划。在更新后的统计信息就绪后启动的查询将使用那些统计信息。这可能会导致重新编译缓存的计划（取决于较旧的统计信息版本）。如果在同一个显式用户事务中出现某些数据定义语言 (DDL) 语句（例如，CREATE、ALTER 和 DROP 语句），则无法更新异步统计信息。

AUTO_UPDATE_STATISTICS_ASYNC 选项设置于数据库级别，并确定用于数据库中所有统计信息的更新方法。它只适用于统计信息更新，而无法用于以异步方式创建统计信息。只有将 AUTO_UPDATE_STATISTICS 设置为 ON 时，将此选项设置为 ON 才有效。默认情况下，AUTO_UPDATE_STATISTICS_ASYNC 选项设置为 OFF。

从以上说明中，我们可以看出，对于大表，还是有可能存在统计信息更新不及时的时候，这时，就可能会影响查询优化器的判断了。
有些人可能有个经验：对于一些慢的查询，他们会想到重建索引来尝试解决。其实这样做是有道理的。因为，在某些时候一个查询突然变慢了，可能和统计信息更新不及时有关，进而会影响查询优化器的判断。如果此时重建索引，就可以让查询优化器知道最新的数据分布，自然就可以避开这个问题。还记得我前面用【set statistics profile on】显示的执行过程表格吗？注意哦，那个表格就显示每个步骤的实际数据量和预估的数据量。要不要重建索引，其实我们可以用【set statistics profile on】来看一下，如果实际数据量和预估的数据量的差值比较大，那么我们可以考虑手工去更新统计信息，然后再去试试。

优化视图查询

再来说说优化视图查询，虽然视图也是由一个查询语句定义的，本质上也是一个查询，但它和一般的查询语句在优化时，还是有所区别的。这里主要的区别在于，视图虽然是由一个查询语句定义的，但如果只去分析这个查询定义，可能得到的意义不大，因为视图多数时候就不是直接使用，而是在使用前，会加上where语句，或者放在其它语句中供from子句所使用。下面还是举个例子吧，在我的演示数据库中有个视图OrdersView，定义代码前面有。我们来看看，如果直接使用这个视图，会有什么样的执行计划出来：

从这个视图可以看出，SQL Server会对表Orders做全表扫描，应该是很低效的。再来看看下面这个查询：

从这个执行计划可以看出，与上面那个就不一样了。前一个查询中对Orders表的查找是使用【Clustered Index Scan】的方式，而现在在使用【Clustered Index Seek】的方式了，最右边二个步骤的成本的百分比也发生了改变。这样就足以说明，优化视图时，最好能根据实际需求，应用不同的过滤条件，再来决定如何去优化。