SQL Server 2005 中的批编译、重新编译和计划缓存问题（1）

核心提示： 在计划缓存中，一个查询计划和多个相关联的执行上下文可以共存，SQL Server 2005 中的批编译、重新编译和计划缓存问题（1）(8)，然而，单个执行上下文（如果没有相关联的查询计划）无法存在于计划缓存中，不缓存派生自并行计划的任何执行上下文——串行或并行，但是

在计划缓存中，一个查询计划和多个相关联的执行上下文可以共存。然而，单个执行上下文（如果没有相关联的查询计划）无法存在于计划缓存中。只要从计划缓存中删除了查询计划，所有相关联的执行上下文也将随之被删除。

当搜索计划缓存以寻找计划重用的机会时，将比较各个查询计划，而不是各个执行上下文。一旦找到了可重用的查询计划，就能找到（导致执行上下文重用）或新生成可用的执行上下文。所以，查询计划重用不一定会导致执行上下文重用。

执行上下文是在“匆忙中 (on the fly)”派生的，其间一个主干执行上下文会在批处理执行开始之前生成。随着执行的进行，将生成必要的执行上下文片断并放入该主干中。这意味着，即便从中删除了特定于用户的信息和查询参数，两个执行上下文也不必完全相同。由于派生自相同查询计划的执行上下文的结构可以彼此不同，因此用于特定执行的执行上下文对性能有轻微的影响。随着计划缓存变“热”并达到稳定状态，这种性能差异的影响会越来越小。

例如：假设批处理 B 包含一个“if”语句。当 B 开始执行时，就会为其生成一个执行上下文。假设在首次执行时，提取了“if”的“true”分支。此外，假设在首次执行时，B 再次由另一个连接提交。因为当时唯一存在的执行上下文正被使用，所以将生成第二个执行上下文，并提供给第二个连接。假设第二个执行上下文提取了“if”的“false”分支。当这两个执行都完成之后，将有第三个连接提交 B。假设 B 的第三个执行选择了“true”分支，如果 SQL Server 为该连接选择了 B 的第一个执行上下文而非第二个执行上下文，那么完成该执行的速度将稍快一些。

可重用批处理 S 的执行上下文，即使 S 的调用顺序有所不同。例如，调用顺序可以是“存储过程 1 --> 存储过程 2 --> S”，而第二个调用顺序可以是“存储过程 3 --> S”。可对 S 的第二次执行重用其第一次执行的执行上下文。

如果批处理执行生成了严重级别高达 11 或更高的错误，那么其执行上下文会被破坏。如果批处理执行生成了一个警告（严重级别为 10），那么执行上下文就不会被破坏。因此，即便没有内存方面的压力——会导致计划缓存缩小，计划缓存中所缓存的（给定查询计划的）执行上下文的数量也会起伏不定。

不缓存并行计划的执行上下文。SQL Server 编译并行查询计划的一个必备条件是：满足了处理器关联掩码和“最高程度的并行”服务器级选项的值（可能是用“sp_configure”存储过程设置）后所剩下的处理器的最低数量大于 1。即使编译了并行查询计划，SQL Server 的“查询执行”组件也可能会从中生成一个串行执行上下文。不缓存派生自并行计划的任何执行上下文——串行或并行。但是，会缓存并行查询计划。