📚 课程目录第2章执行计划深度解读

2. 执行计划深度解读

图形化执行计划是 SQL Server 优化器在编译阶段生成的一棵“运算符树”，它把一条 T-SQL 语句的物理执行方式翻译成可读的节点与箭头。理解它，关键不是记住图标长什么样，而是理解三件事：数据从哪里来、经过哪些运算符、每个运算符的代价与行数估计是否合理。本节围绕图形化执行计划的读法、属性含义、运算符代价构成，以及数据流方向与并行区域的识别展开。

一、图形化执行计划的基本结构

在 SSMS 中启用“包括实际执行计划”（快捷键 Ctrl+M）后执行语句，结果集下方会出现一个可点击的执行计划标签页。它由若干运算符节点和连接节点的箭头组成。箭头方向表示数据行的流动方向：从叶子节点（数据源，如聚集索引扫描、表扫描）流向根节点（最左侧的 SELECT、INSERT 等语句级节点）。因此，读图应从右向左、从下向上，而不是从左往右。

每个节点上通常显示三行信息：运算符名称、估计行数（如“估计的行数 1”）、以及该节点相对于整棵计划的代价百分比。鼠标悬停节点会弹出属性面板，包含 I/O 代价、CPU 代价、估计行数、实际行数、实际执行次数、谓词、输出列表等。图形只是入口，属性面板才是判断依据。

二、属性含义：估计行数、实际行数与代价

属性面板中最值得关注的是估计行数（Estimated Number of Rows）与实际行数（Actual Number of Rows）。估计行数来自优化器的基数估计（Cardinality Estimation），它基于统计信息、谓词选择度和连接选择度推算；实际行数只有实际执行计划才有。两者差距过大，往往意味着统计信息过期、参数嗅探或谓词写法导致估计失真，进而引发内存授予不足、溢出到 tempdb 或错误的连接算法选择。

另一个关键属性是运算符代价（Operator Cost）。它由 I/O 代价与 CPU 代价组成，是优化器基于模型估算出的相对值，不是真实耗时。图形上显示的百分比是该节点代价占整棵计划总代价的比例。因此，一个显示 42% 的 Hash Match 并不一定真的消耗了 42% 的时间，它只是优化器认为它“贵”。判断真实瓶颈应结合实际行数、实际执行次数、以及 SET STATISTICS IO/TIME 的输出。

提示：在 SSMS 中右键执行计划节点选择“属性”，可查看完整属性列表。若节点上出现黄色感叹号，表示存在警告，常见的有“缺少索引”“排序溢出”“并行度不足”等，应优先排查。

三、运算符代价的构成与常见运算符

SQL Server 的代价模型把每个运算符的代价拆成 I/O 与 CPU 两部分。扫描类运算符（Table Scan、Clustered Index Scan）的 I/O 代价通常较高，因为需要读取大量页；而 Seek 类运算符（Index Seek）的 I/O 代价低，因为只定位少量页。连接类运算符中，Nested Loops 的 CPU 代价随外层行数线性增长，Hash Match 需要建立哈希表，内存与 CPU 代价较高，Merge Join 则要求两侧输入按连接键有序。

聚合与排序运算符（Stream Aggregate、Sort、Hash Match Aggregate）往往成为代价热点。Sort 的代价与行数、排序键宽度相关，若估计行数偏低，排序可能溢出到 tempdb，实际代价远高于估计。识别这类问题，应查看 Sort 节点的“警告”属性以及实际行数是否远超估计。

四、数据流与并行区域的识别

并行执行计划中，数据流不再是单条直线，而是被交换运算符（Exchange Operators）切分成多个并行区域。常见的交换运算符有：Gather Streams（把多个并行流汇聚成单流）、Distribute Streams（把单流分发到多个线程）、Repartition Streams（按某键重新分区）。并行区域就是被这些交换运算符分隔开的、内部以多线程方式执行的子树。

识别并行区域的方法是：从根节点向左看，遇到第一个 Gather Streams 时，其右侧的整棵子树通常就是一个并行区域。并行区域内的运算符会以多个线程同时执行，因此实际行数是所有线程行数之和，实际执行次数也可能大于 1。若发现某个并行区域内的运算符实际行数远大于估计行数，或出现“并行度不足”的警告，说明优化器对并行度的估计与实际负载不匹配，可考虑调整 MAXDOP 或更新统计信息。

注意：并行计划并不总是更快。对于小结果集或短查询，并行的线程协调开销可能超过收益。SQL Server 会根据代价阈值（Cost Threshold for Parallelism，默认 5）决定是否并行。若发现小查询被并行化，可适当提高该阈值。

五、读图实操：一个可复现的观察流程

下面给出一个可复现的观察流程，帮助把上述概念落到实际操作上。假设有一张订单表 Orders，包含 OrderID、CustomerID、OrderDate、Amount 等列，数据量约 500 万行。

-- 示例：观察执行计划中的估计行数与实际行数差异
SET STATISTICS IO ON;
SET STATISTICS TIME ON;

SELECT CustomerID, SUM(Amount) AS TotalAmount
FROM Orders
WHERE OrderDate >= '2024-01-01'
  AND OrderDate <  '2024-02-01'
GROUP BY CustomerID
ORDER BY TotalAmount DESC;

执行后，在图形化执行计划中依次观察：

找到最右侧的叶子节点，查看它是 Index Seek 还是 Clustered Index Scan，以及估计行数。
查看 Sort 或 Hash Match 节点，比较估计行数与实际行数。若实际行数明显大于估计行数，说明统计信息可能未覆盖该日期范围。
若计划中出现 Gather Streams，确认其右侧是否为并行区域，并查看各并行分支的实际行数是否均衡。
结合 SET STATISTICS IO 输出的逻辑读次数，判断 I/O 代价是否与图形显示的代价比例一致。

通过这样的观察，可以把“图形上显示的代价”与“实际资源消耗”对应起来，避免仅凭百分比下结论。执行计划是优化器对世界的理解，而实际行数与 I/O 统计才是世界本身。两者对照，才能定位真正的性能问题。