看懂执行计划是 SQL 调优最核心的一步，它揭示数据库真实执行路径，需重点关注高成本算子、统计信息准确性及实际与预估行数差异，结合场景精准优化。
看懂执行计划，是 SQL 调优最核心的一步。它不是“猜”，而是数据库告诉你的真实执行路径——哪张表先查、怎么连、走不走索引、有没有临时表、是否排序溢出磁盘……关键不在堆参数，而在读懂每一步的成本和行为。
重点关注这几个算子（Operator）
执行计划里不是所有节点都重要，优先盯住这些高频性能杀手：
- Table Scan / Clustered Index Scan：全表 / 全索引扫描。数据量大时极慢。检查是否有可用索引，或 WHERE 条件是否导致索引失效（如对字段做函数、隐式转换）
- Index Seek：理想状态，按索引快速定位。确认 Seek Predicate 里用的是高选择性列（比如 id、订单号），而非性别、状态这类低区分度字段
- Key Lookup / RID Lookup：说明非聚集索引查到了，但还要回主键索引取其他字段。可考虑覆盖索引（INCLUDE 所需列）消除回表
- Hash Match / Sort / Spool：常出现在 JOIN、GROUP BY、ORDER BY 中。若数据量不大却出现 Hash 或 Sort，大概率是缺少合适索引或统计信息过期
- Warning 图标（黄色感叹号）：比如“No Join Predicate”“Convert Issue”“Missing Index”，直接点出隐患，别跳过
看懂成本数字背后的含义
执行计划顶部显示的“Estimated Subtree Cost”是相对值，用于比较不同计划间开销大小，不是毫秒数。真正要关注的是：
- 哪个算子占总成本 70% 以上？它就是优化突破口
- “Actual Rows”远大于“Estimated Rows”？说明统计信息不准，UPDATE STATISTICS 或重新生成可能立竿见影
- “Reads”“Executes”次数异常高？比如 Nested Loop 里内层表被反复扫描上千次，就要考虑改用 Hash Join 或加驱动条件
结合实际场景快速判断优化方向
不用死记规则，按 常见问题 反推：
- 查询变慢了，但 SQL 没改 → 检查统计信息、执行计划是否变更（可能因数据分布变化触发了更差的计划）
- 加了索引没生效 → 看 Seek 还是 Scan；看 Predicate 是否能下推；看是否用了 SELECT * 导致 Key Lookup 过多
- 分页查询（OFFSET FETCH）越来越卡 → 执行计划里出现 Top + Sort + Spool，数据量大时建议改用游标分页或覆盖索引 + 上一页最大值过滤
- JOIN 结果比预期多很多 → 查看 JOIN 类型是否写错（把 INNER 写成 CROSS），或 ON 条件漏写、逻辑有歧义
基本上就这些。执行计划不是越短越好，也不是索引越多越好。关键是让数据库“少干活、走对路”。每次调优前先看计划，改完再对比——眼见为实，比经验更可靠。
