SQL Server查询处理器机制与结构（下）

把计划放入缓存之后，SQL Manager 按照执行要求逻辑进行检查，确定是否有更改的内容，是否需要重新编译。即使编译到执行之间时间间隔只有几毫秒，也可能有人会执行一条数据定义语句 (DDL)，为关键的表加了索引。这种可能性不大，但是确实存在，因此 SQL Server 必须考虑这一点。有几种情况 SQL Server 必须重新编译存储规划。元数据的修改，例如增加或删除索引，是重新编译的最主要的原因。服务器必须确信所使用的计划反映了索引的当前状态。

重新编译的另一种原因是统计情况发生变化。SQL Server 还维护不少数据使用频率的统计信息。如果数据使用频率分布情况变化很大，则可能需要另一个查询计划以便更有效地执行。SQL Server 跟踪表数据插入和删除的统计数据，如果数据修改的数量超过根据表的容量变化的某一阈值，则需要根据新的分布数据重新编译计划。

图 7 给出了编译和执行过程的流程。

　　

图 7. 编译与执行

注意，实际参数的改变并不会导致重新编译，环境的改变，例如可用内存的增加或所需数据的增加，也不会导致重新编译。

执行是比较简单的，如果需要执行的查询很简单，如"插入一行"，或从带有唯一索引的表中查询数据，则执行处理会非常简单。但是，很多查询都要求大量的内存以提高运行效率，或至少从所增加的内存得到好处。在 SQL Server 6.5 中，每个查询能够使用的内存限制在 0.5MB 或 1MB 以下。有一个控制查询内存使用的参数，称为排序页。顾名思义，它主要是限制可能占用大量内存的排序操作。不管要处理的排序有多大，在 SQL Server 6.5 中，内存的使用不能超过 1MB。即使您使用的机器上配置了 2GB 内存，需要对数百万行数据排序，也不能突破限制。显然，复杂的查询不能高效执行，因此 SQL Server 开发人员增加了 SQL Server 7.0 的能力，使得单个查询可以使用大量的内存。

另一个问题随之而来。一旦您开始允许查询使用大量内存，就必须确定如何把内存分配给可能需要内存的很多查询。SQL Server 按照以下方法解决这个问题。当查询计划优化之后，优化器要确定有关给该查询使用的内存的两部分信息。第一，该查询有效执行所需要的最小内存，该参数与查询计划一起存放。优化器还要确定该查询可以获益的

过程缓存

我们在前面已经多次提到 SQL Server 的过程缓存。需要注意的是，SQL Server 7.0 的过程缓存与以前的版本有很大不同。在早期的版本中，有两个有效配置值用于控制过程缓存的容量：一个是定义 SQL Server 总可用内存的固定容量，另一个是供存储查询计划使用的内存百分比（扣除满足固定需要的内存）。在老版本中，特定 SQL 语句从不存入缓存，只有存储过程计划才存入其中。在 SQL Server 7.0 中，内存的总容量是动态的，用于查询计划的空间也是经常变化的。

在处理查询时，SQL Server 7.0 首先会问的是：这个查询既是特定的又是易于编译的吗？如果是，SQL Server 就根本不会将其写入缓存中。将来重新编译这些计划比把复杂的计划或数据页推出内存更合算。如果查询不是特定的或不易于编译，则 SQL Server 会从缓存区中分配一些缓存内存存储该计划，因为该缓存区是 SQL Server 7.0 用来满足 99% 内存需求的唯一来源。在少数特殊情况下，SQL Server 会直接从操作系统中分配大块内存，但是这种情况极为罕见。SQL Server 的管理是集中式的。