为什么我的两台服务器之间的实际执行计划不同？

Question

我有一个在生产和开发环境中运行的 SQL Server 查询。完全相同的查询。

SELECT DISTINCT 
    [Record_Transformation_ACCRUALS],
    [Record_Transformation_FA:AMORTIZATION],   
    [Record_Transformation_BONUS:AMORTIZATION],
    [Record_Transformation_CPH:BYLABOUR],
    [Record_Transformation_CPH:BYTARGETHOURS],
    [Record_Transformation_OVERHEAD:CULTURE],
    [Record_Transformation_DEDICATED COSTCENTER],
    [Record_Transformation_PUSHDOWN:EXPENSE],
    [Record_Transformation_OVERHEAD:FACILITIES],
    [Record_Transformation_OVERHEAD:GENOME],
    [Record_Transformation_TAXES:MANAGEMENT],
    [Record_Transformation_TAXES:MARKETING],
    [Record_Transformation_OVERHEAD:OFFICETECH],
    [Record_Transformation_EXPENSE:PASSTHROUGH],
    [Record_Transformation_OVERHEAD:PEOPLEPRACTICES],
    [Record_Transformation_OVERHEAD:RECRUITING],
    [Record_Transformation_TAXES:SALES],
    [Record_Transformation_Static Transfer],
    [Record_Label] 
FROM
    Warehouse_20181204 
WHERE 
    Is_Target_Employee = 1 OR Is_Source_Employee = 1

我们比较了这两个表的创建脚本，它们是相同的（除了相关表的名称）。

我们还验证了它们都在使用聚集列存储索引。

在开发过程中，此查询只需不到一秒钟的时间。在 prod 上大约需要一分钟。起初我们认为数据的大小可能是问题所在，但差异很小（几十万行）。

然后我们检查了两者的实际执行计划。在 dev 上，实际的执行计划是：

在 prod 上，实际的执行计划却大不相同：

我们发现自己很难理解为什么会这样。我们已验证 SQL Server 的版本是相同的：

Microsoft SQL Server 2017 (RTM-CU5) (KB4092643) - 14.0.3023.8 (X64)   
Web Edition (64-bit) on Windows Server 2016 Datacenter 10.0 <X64> (Build 14393:) (Hypervisor)

我的问题有两个：

1. 我们如何确定为什么 prod 和 dev 之间的执行计划如此不同？
2. 在给定类似数据集的情况下，如何让 prod 环境与 dev 环境一样快地运行？

编辑：

一些额外要求的细节：

• 两台服务器都有 8G 内存，运行时都有超过 1G 的空闲空间
• 两台服务器都有 2 个处理器
• 硬件与您得到的一样 - 两个相同大小的 aws 实例
• 我们已验证两个表和聚集列存储索引的 sql 是相同的

希望这些对当前 SQL 计划的所有其他细节有所帮助：

DEV sql 计划：https://gist.github.com/klick-barakgall/17a7ce926777a3257f7eecb32859458e

PROD sql 计划：https://gist.github.com/klick-barakgall/76eabf1008f5bfb0c51259c2ba3f509d

为那些有兴趣深入研究执行的人添加粘贴计划的链接。

DEV

PROD

Answer 1

DISTINCT 使您的查询简写为：

SELECT
    [Record_Transformation_ACCRUALS],
    [Record_Transformation_FA:AMORTIZATION],   
    [Record_Transformation_BONUS:AMORTIZATION],
    [Record_Transformation_CPH:BYLABOUR],
    [Record_Transformation_CPH:BYTARGETHOURS],
    [Record_Transformation_OVERHEAD:CULTURE],
    [Record_Transformation_DEDICATED COSTCENTER],
    [Record_Transformation_PUSHDOWN:EXPENSE],
    [Record_Transformation_OVERHEAD:FACILITIES],
    [Record_Transformation_OVERHEAD:GENOME],
    [Record_Transformation_TAXES:MANAGEMENT],
    [Record_Transformation_TAXES:MARKETING],
    [Record_Transformation_OVERHEAD:OFFICETECH],
    [Record_Transformation_EXPENSE:PASSTHROUGH],
    [Record_Transformation_OVERHEAD:PEOPLEPRACTICES],
    [Record_Transformation_OVERHEAD:RECRUITING],
    [Record_Transformation_TAXES:SALES],
    [Record_Transformation_Static Transfer],
    [Record_Label] 
FROM   Warehouse_20181204 
WHERE  Is_Target_Employee = 1 OR Is_Source_Employee = 1
GROUP BY 
    [Record_Transformation_ACCRUALS],
    [Record_Transformation_FA:AMORTIZATION],   
    [Record_Transformation_BONUS:AMORTIZATION],
    [Record_Transformation_CPH:BYLABOUR],
    [Record_Transformation_CPH:BYTARGETHOURS],
    [Record_Transformation_OVERHEAD:CULTURE],
    [Record_Transformation_DEDICATED COSTCENTER],
    [Record_Transformation_PUSHDOWN:EXPENSE],
    [Record_Transformation_OVERHEAD:FACILITIES],
    [Record_Transformation_OVERHEAD:GENOME],
    [Record_Transformation_TAXES:MANAGEMENT],
    [Record_Transformation_TAXES:MARKETING],
    [Record_Transformation_OVERHEAD:OFFICETECH],
    [Record_Transformation_EXPENSE:PASSTHROUGH],
    [Record_Transformation_OVERHEAD:PEOPLEPRACTICES],
    [Record_Transformation_OVERHEAD:RECRUITING],
    [Record_Transformation_TAXES:SALES],
    [Record_Transformation_Static Transfer],
    [Record_Label] 

优化器尝试满足此类查询的两种最常见的方式。首先，它为Is_Target_Employee = 1 OR Is_Source_Employee = 1 过滤列存储索引；这就是您计划中的过滤器所显示的内容。接下来，要处理 GROUP BY（或 DISTINCT），它将：

1. 对行进行排序，然后使用Stream Aggregator 返回一个不同的集合（如 prod 执行计划中所示） 或
2. 使用哈希匹配过滤行并返回不同的集合（如开发版所示）

我怀疑优化器选择了不同的计划，因为基数估计有很大不同。显然，开发计划表现得更好。它可能会表现得更好，因为在这种情况下哈希匹配计划更有效，它更有可能在 Dev 中表现得更好，因为您在 Dev 中获得了并行执行计划，在 Prod 中获得了串行计划。

我建议的行动方案是： 使用查询提示在 Prod 中运行您的查询 -

OPTION (QUERYTRACEON 8649);

这将强制优化器运行并行计划。如果您没有获得并行计划，那么您将遇到不同的问题（可能 Prod 中的 MAXDOP 设置设置为 1）。如果您确实获得了并行计划，并且它提高了性能，那么您已经确定了问题（您需要并行计划）。如果并行计划不能解决问题，那么您可能需要考虑在该表上使用非聚集的过滤列存储索引，该索引包括查询中的所有列，然后使用以下内容进行过滤：

WHERE Is_Target_Employee = 1 OR Is_Source_Employee = 1

您现在正在执行大扫描，读取大量您不需要阅读的行。

如有任何问题，请回复。

2018 年 12 月 6 日更新： 很抱歉更新晚了，很多工作都出现了。

我进一步研究了执行计划，发现了一些有趣的事情。在阅读@Martin_Smith 发布的内容之前，我截取了这些屏幕截图：

我 100% 同意串行与并行执行计划不是这里的问题，但就您的产品计划而言，串行运行会使糟糕的执行计划变得更慢。正如 Martin 解释的那样，问题在于哈希匹配计划是一个更好的计划。

两个计划都从列存储索引中检索相似数量的行（Dev 中为 5M，Prod 中为 6M）。在每个计划中，所有行都被过滤，但在 Prod 计划中全部 em> 行由排序运算符处理再次，而开发计划中的 338 行具有哈希聚合。

无论您投入多少 CPU：针对 630 万行的 19 列排序都会很慢，尤其是串行计划。并行性 IMO 的最佳用途之一是处理诸如此类的大型排序。也就是说，不应该需要排序。我以前见过这种情况，当优化器可以使用排序（如在您的产品计划中）或使用哈希（如在您的开发计划中）解决查询时 - 当您强制并行执行时，它将选择带有哈希的计划计划。我怀疑在您的情况下强制执行并行计划会导致优化器选择使用哈希的计划。

最后 - 我之前忘了提这个，不要在 Prod 中使用 OPTION (QUERYTRACEON 8649)；它是无证的。我用它来测试。在产品中使用make_parallel by Adam Machanic

Answer 2

串行与并行并不是真正的问题，因为无论如何您的最大并行度只有 2。

导致您的慢查询的原因是内存授予不足和大量排序溢出（到级别 8）

您的查询返回 305 行，但 SQL Server 在一个计划中估计 2,561,980 而在另一个计划中估计 3,709,060。

对于 305 行，您需要一个哈希聚合，因为它只需要存储 305 个不同的分组值的内存，而不需要存储整个 600 万行的内存以及排序使用的额外开销。

即使在具有哈希聚合的计划中，输出行数的高估也意味着您会收到过多的内存授予警告。

查询内存授权检测到“ExcessiveGrant”，这可能会影响 可靠性。授权大小：初始 831,800 KB，最终 831,800 KB，已使用 20,480 KB。

为此，您可以尝试以下方法来创建多列统计信息，以便准确估计组数，以便 SQL Server 自然选择具有适当大小的内存授予的哈希组。 FULLSCAN 可能不需要，但是当我设置测试时，默认采样似乎不足以让优化器使用新统计数据中的密度信息和新基数估计器。

CREATE STATISTICS SomeName ON  Warehouse_20181204  (
    [Record_Transformation_ACCRUALS],
    [Record_Transformation_FA:AMORTIZATION],   
    [Record_Transformation_BONUS:AMORTIZATION],
    [Record_Transformation_CPH:BYLABOUR],
    [Record_Transformation_CPH:BYTARGETHOURS],
    [Record_Transformation_OVERHEAD:CULTURE],
    [Record_Transformation_DEDICATED COSTCENTER],
    [Record_Transformation_PUSHDOWN:EXPENSE],
    [Record_Transformation_OVERHEAD:FACILITIES],
    [Record_Transformation_OVERHEAD:GENOME],
    [Record_Transformation_TAXES:MANAGEMENT],
    [Record_Transformation_TAXES:MARKETING],
    [Record_Transformation_OVERHEAD:OFFICETECH],
    [Record_Transformation_EXPENSE:PASSTHROUGH],
    [Record_Transformation_OVERHEAD:PEOPLEPRACTICES],
    [Record_Transformation_OVERHEAD:RECRUITING],
    [Record_Transformation_TAXES:SALES],
    [Record_Transformation_Static Transfer],
    [Record_Label] ) WITH FULLSCAN

或者您可以考虑重组您的数据库，使 20 列左右的列与 305 行（加上数据中存在但被 WHERE 子句排除的任何其他组合）在一个单独的表中，并且您的原始表只有一个指向这个新表的 id。

然后您可以将其重写为小表中的 SELECT，其中 groupid IN (SELECT groupid FROM large table WHERE....)