执行计划是数据库执行SQL的底层操作步骤图，揭示是否走索引、连接方式、排序溢出等关键信息；需重点关注Table Scan、Key Lookup、Sort/Spill及行数偏差等信号，并结合统计信息更新、索引优化与实际运行验证迭代调优。
理解执行计划是性能优化的起点
执行计划（Execution Plan）是数据库引擎为执行SQL语句所生成的底层操作步骤图。它不直接告诉你“为什么慢”，但清楚展示了“怎么执行”——比如是否走索引、是否触发全表扫描、连接方式是嵌套循环还是哈希连接、是否有临时表或排序溢出等。很多调优失败，根源在于跳过执行计划，只凭经验改写SQL或加索引。
重点关注执行计划中的关键算子与代价信号
看执行计划不能只扫一眼，要盯住几个高风险信号：
- Table Scan / Clustered Index Scan：表示未命中有效索引，尤其在大表上应优先排查WHERE、JOIN或ORDER BY字段的索引覆盖情况；
- Key Lookup（书签查找）：说明非聚集索引能定位行，但需回表取其他列——可通过添加INCLUDE列构建覆盖索引消除；
- Sort / Hash Match（Build/Probe） / Spill to TempDB：意味着内存不足导致磁盘参与计算，常见于未加LIMIT的ORDER BY、GROUP BY大数据量聚合或大结果集JOIN；
- Estimated Rows vs Actual Rows 严重偏离（如差10倍以上）：统计信息过期或查询谓词复杂（如函数包裹列、OR条件、隐式转换），会误导优化器选择低效路径。
结合真实场景验证与迭代优化
执行计划只是“预估”，必须配合实际运行验证。例如：
- 用SET STATISTICS XML ON获取图形化执行计划，观察各节点“实际影响行数”和“实际执行时间”；
- 对慢查询先UPDATE STATISTICS更新统计信息，再看执行计划是否改善；
- 尝试强制使用索引（WITH (INDEX=idx_name)）或重写JOIN顺序，对比执行计划变化与逻辑读/物理读差异；
- 报表类SQL常含多层子查询或CTE，注意SQL Server可能将CTE展开为重复计算——可改用临时表+显式索引控制中间结果规模。
索引设计要匹配执行计划暴露的真实访问模式
别迷信“给WHERE字段加索引”。执行计划会告诉你真正需要什么：
- 如果计划显示大量Seek + Key Lookup，就把SELECT列表中常查的列加到索引的INCLUDE中；
- 如果ORDER BY col1, col2总触发Sort，且该排序在WHERE后仍有千行以上，则考虑复合索引(col1, col2)并确保WHERE条件能利用前导列；
- 报表汇总常用GROUP BY a, b配SUM(c)，可建索引(a, b) INCLUDE (c)，让聚合在索引内完成，避免SORT或HASH AGG；
- 日期范围查询（如WHERE dt BETWEEN '2024-01-01' AND '2024-06-30'）若常走Scan，检查是否因分区未对齐、或索引列顺序把dt放在非前导位。
