两台服务器，不同的执行计划。运行时间有几个数量级的差异

Question

两台服务器，Development 和 Live。实时服务器是一个 Amazon RDS SQL Server Web 实例。两台服务器都具有相同的架构和数据。几何列上有一个很好的空间索引。在我的开发服务器上，查询在 < 30 毫秒内执行。在实时服务器上，查询需要 > 20 分钟。

检查执行计划表明它们完全不同。一方面，在我的开发环境中，查询是并行化的，而在实时服务器上则不是。

• 我重建了索引并重新生成了统计信息。
• 我无法解释巨大的差异。
• 服务器的 DOP 相同。
• 在执行查询期间，实时服务器的 CPU 受到 100% 的冲击。

如果您对原因或如何最好地诊断问题有任何见解，我将不胜感激。

DECLARE @geoBoundary geometry;
SET @geoBoundary = geometry::STGeomFromText('POLYGON((407439.5 108792.25, 408022.5 108792.25, 408022.5 108575.75, 407439.5 108575.75, 407439.5 108792.25))', '0');

SELECT
     ogr_geometry.ToString() AS strGeometry
    ,ogr_geometry
FROM inspire as geo
WHERE geo.ogr_fid IN
(
    SELECT
        geo.ogr_fid
    FROM .inspire as geo
    WHERE
    (
        (@geoBoundary.STContains(geo.ogr_geometry) = 1)
    )
    UNION
    SELECT
        geo.ogr_fid
    FROM .inspire as geo
    WHERE
    (
        (@geoBoundary.STOverlaps(geo.ogr_geometry) = 1)
    )
)

• 在cost threshold for parallelism两台服务器上为5（默认值）。
• 开发实例有4个物理核，8个逻辑核；实时实例有 8 个虚拟核心。
• max server memory 两者都是一样的。
• 开发实例为SQL Server 12.0.4100.1；Live 是 SQL Server Web 12.0.2100.60
• 实际行和预期行之间存在巨大差异。但是，在重建统计数据后，这种情况仍然存在。
• 我清除了计划缓存。它一直在编制相同的计划。
• 执行计划可以从这里下载。

Answer 1

比较所提供的两个执行计划的详细信息：

• 慢速计划是在内部版本 11.0.2100.60 上编译的 - SQL Server 2012 RTM
• 快速计划是在内部版本 12.0.4100.1 上编译的 - SQL Server 2014 SP1
• Slow plan 使用版本70基数估计器
• 快速计划使用版本120基数估计器
• Slow plan 估计可用 DOP 为2（可见 CPU 的一半）
• Fast 计划估计可用 DOP 为4（可见 CPU 的一半）
• 两者之间的估计可用内存授予也不同
• 编译期间使用的参数值相同

由于软件和硬件存在如此多的基本差异，因此计划有所不同也就不足为奇了。

理想情况下，开发和测试环境应尽可能与生产相匹配。它们当然应该使用相同版本的 SQL Server（注意 2012 年的安装仍然在 RTM 上，两个完整的服务包和七个进一步的累积更新。

如果没有查询中涉及的模式的纯统计副本，就很难知道如何建议来改进 2012 年的查询计划。如果您习惯使用提示，您可以尝试添加：

OPTION (LOOP JOIN, HASH JOIN, CONCAT UNION, QUERYTRACEON 8649);

在查询结束时鼓励优化器朝着更好的计划的大方向前进。该提示集合的最后一部分（为查询设置跟踪标志 8649）未记录，并且不支持生产。

这些提示可能会成功，也可能不会成功，因为根本问题是 70 级基数估计器提供的基数估计不准确。查询重写或索引更改也可能会成功，但从这里猜测确实不切实际。

相关阅读：

强制并行执行计划
UAT 和 PROD 上的不同计划
“相同”查询的多个计划
“相同”服务器的不同计划