sql-server-2008-r2 – UAT和PROD服务器上执行计划的差异

缓冲池的潜在大小也会影响优化程序的数据访问成本模型.模型中的一个假设是每个查询都以冷缓存开始 – 因此首先访问页面会产生物理I / O.该模型确实试图考虑重复访问将来自缓存的可能性,该因素取决于缓冲池的潜在大小等.

问题中显示的查询计划中的聚集索引扫描是重复访问的一个示例;对于嵌套循环半连接的每次迭代,扫描被重绕(重复,没有相关参数的改变).半连接的外部输入估计28.7874行,并且这些扫描的查询计划属性显示估计的倒带为27.7874.

同样,仅在SQL Server 2012中,计划的根迭代器显示优化器硬件依赖关系部分中缓存的估计页数.此编号报告成本算法的一个输入,该算法旨在考虑重复页面访问来自缓存的可能性.

结果是,具有更高配置的最大缓冲池大小的安装将倾向于降低与具有较小最大缓冲池大小的安装相比读取相同页面的扫描(或搜索)的成本.

在简单的计划中,通过比较(估计的执行次数)*(估计的CPU估计的I / O)与估计的操作符成本,可以看到重绕扫描的成本降低.由于半连接和并集的影响,示例计划中的计算更复杂.

尽管如此,问题中的计划似乎表明,重复扫描和创建临时索引之间的选择非常精细.在具有较大缓冲池的计算机上,重复扫描的成本略低于创建索引.在具有较小缓冲池的计算机上,扫描成本减少了较少的量,这意味着索引假脱机计划看起来稍微便宜一点.

计划选择

优化器的成本模型做出了许多假设,并包含大量详细的计算.并不总是(或者甚至通常)可以遵循所有细节,因为并非所有我们需要的数字都会暴露,并且算法可以在不同版本之间进行更改.特别是,应用于考虑到遇到缓存页面的机会的缩放公式并不为人所知.

更重要的是,在这种特殊情况下,优化器的计划选择基于不正确的数字. Clustered Index Seek的估计行数为28.7874,而在运行时遇到256行 – 几乎是一个数量级.我们无法直接看到优化器关于28.7874行内值的预期分布的信息,但它也很可能是非常错误的.

当估计错误时,计划选择和运行时性能基本上不比偶然性好.具有索引假脱机的计划恰好比重复扫描更好,但认为增加缓冲池的大小是导致异常的原因是错误的.

在优化器具有正确信息的情况下,它将产生一个体面的执行计划的可能性要大得多.具有更多内存的实例通常比具有更少内存的另一个实例在工作负载上表现更好,但是没有保证,尤其是当计划选择基于不正确的数据时.

两个实例都以自己的方式建议缺少索引.一个报告显式缺失索引,另一个报告使用具有相同特征的索引假脱机.如果索引提供良好的性能和计划稳定性,那可能就足够了.我倾向于重写查询,但这可能是另一个故事.

（编辑：核心网）

【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容!