看懂执行计划是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条件漏写、逻辑有歧义
基本上就这些。执行计划不是越短越好，也不是索引越多越好。关键是让数据库“少干活、走对路”。每次调优前先看计划，改完再对比——眼见为实，比经验更可靠。
