实际查询计划估计成本和 dm_exec_query_stats 工作时间不融合

Question

我清除了我的统计数据并运行了我的查询。实际执行计划的总估计成本为 0.61。我使用dmv 中的total_worker_time列dm_exec_query_stats来计算平均 20858 微秒的 CPU 时间：

(SUM(query_stats.total_worker_time) / SUM(query_stats.execution_count))

该计划推荐了一个索引，我创建了该索引。我清除了我的统计信息，然后再次运行查询。这一次，该计划在顶层的总估计成本为 0.37。我dm_exec_query_state再次检查了dmv，现在平均 CPU 时间为 51536 微秒。

我原以为工人的时间大约是一半，而不是两倍！我在这里错过了什么吗？为什么查询计划的改进没有反映在 exec 查询统计信息中？两个计划在这里上传：

计划1

计划2

Answer 1

估计成本是 SQL Server 查询优化器估计的查询成本的无单位度量。仅仅因为查询 A 的估计成本低于查询 B 并不意味着查询 A 将比查询 B 更有效。查询优化器对您的硬件、当前工作负载和可能与您的系统不完全匹配的数据进行假设。可能存在模型限制或 SQL Server 可能无法访问完美信息。即使在配置良好且查询编写良好的服务器上，您几乎肯定不会看到估计的查询成本与 CPU 时间完全相关。请记住，查询成本还包括更多因素，而不仅仅是 CPU 时间。

您在实际查询计划中看到的估计成本实际上仍然是一个估计值。如果计划形状没有因重新编译而改变，则它将与估计计划的估计成本具有相同的值。考虑以下简单查询：

SELECT t1.high AS high, t2.high AS high2
FROM master..spt_values t1
CROSS JOIN master..spt_values t2
OPTION (FAST 1);

对于估计计划，我得到的总估计成本为 0.0065704。对于实际计划，即使返回了 6431296 行而不是单个估计行，我仍然估计成本为 0.0065704。如果您想看一看，实际计划已上传到粘贴计划。

如果我不得不猜测为什么您的查询速度较慢，我将从节点 42 处的索引假脱机开始：

添加索引后，您的查询现在具有索引假脱机，这很奇怪。您可能以错误的顺序使用键列创建了索引。查看代码fn_get_samples并评估您的索引是否真的是最好的。有时，SSMS 向您建议的索引可能表明键列的顺序不佳。您还可以考虑将NO_PERFORMANCE_SPOOL提示添加到您的查询中，但这可能不是正确的纠正措施。

Answer 2

添加到乔的答案：

如果：

• 每个计划算子的基数估计都是完美的；和
• 每个运营商的（不可见的）派生统计数据准确反映了数据分布；和
• 优化器的 CPU 和 I/O 成本成本模型与您的硬件完全匹配；和
• 优化器所做的所有简化建模假设都对您的数据有效
• 查询在执行期间没有遇到等待
• ＆ 。C

...那么您可能会发现估计的计划成本和实际执行时间之间存在某种关联。

事实上，优化器的成本模型正是这样：一个模型；已经证明在给定任意输入 SQL 的情况下，在具有不同性能特征的硬件上，针对一系列数据库模式运行的情况下，能够快速选择合理的执行计划。如果你仔细想想，这真是一项了不起的成就。

无论如何，上述考虑都不是特别适合您的查询，因此它们执行相反的期望也就不足为奇了。此外，这两个查询都运行得相对较快（14 毫秒和 46 毫秒），这完全在查询优化器非常满意的范围内。

换句话说：两个计划都“足够好”。如果您需要更接近理想状态，则必须执行详细的手动分析，以确定需要对查询或物理数据库设计进行哪些更改才能使其运行得更快（而不是查询真的会在预生产中运行） -发布 SQL Server vNext）。