数据库工程：Explain执行计划对比实战指南‌

数据库工程：Explain执行计划对比实战指南‌

去年合肥蜀山一家本地生活服务平台上线暑期消费券活动，活动开启3分钟，平台的用户核销接口直接大面积超时，数据库CPU使用率瞬间冲到99%，运维团队连续重启了3次数据库实例，问题都没有得到缓解，眼看着上千万的消费券即将过期，技术团队急得团团转。后来负责SQL优化的工程师没有直接重启服务，而是从慢查询日志里捞出了3条高频超时的SQL，用Explain分别导出它们的执行计划，和上周正常运行时的执行计划做逐字段对比，只用了12分钟就定位到了根因：运营人员前一天凌晨上线的一条临时数据变更脚本，把3张核心表的联合索引标记成了无效状态，优化器直接放弃了走索引，切换成全表扫描，原本20毫秒就能跑完的核销SQL直接涨到了17秒。团队紧急重建了3个失效的索引，不到5分钟接口就恢复了正常，上千万的消费券顺利完成了核销，没有出现大面积的用户投诉。很多一线开发人员对Explain的认知还停留在“看有没有走索引”的初级阶段，拿到执行计划只会扫一眼type字段，根本不会做前后版本的全字段对比，遇到优化器选错执行计划的隐蔽故障，排查几个小时都找不到根因。90%的线上慢查询隐蔽故障，不需要抓取内核堆栈，不需要分析锁等待日志，只要掌握Explain执行计划的标准化对比方法，就能在十几分钟内定位到问题根源。接下来我们就结合合肥本地生活平台、网约车出行平台、政务预约系统三个真实故障场景，从Explain对比的核心逻辑、全字段对比规则、实战故障排查全流程拆解，帮你把Explain从一个简单的查看工具，变成排查慢查询故障的核心利器。

一、Explain执行计划对比的核心底层逻辑

很多人用Explain只会单独看当前的执行计划，完全没有建立“基准对比”的思维，遇到性能抖动的故障，根本不知道从哪里下手。Explain的核心价值从来不是告诉你当前SQL有没有走索引，而是通过和历史正常版本的执行计划做逐字段对比，快速发现优化器的决策变化，定位那些隐蔽的性能抖动根因。

1、SQL的性能不会凭空突然变差，99%的突发慢查询，对应的执行计划一定和历史正常版本存在至少一个关键字段的差异，你不需要去猜哪里出了问题，只要把两个版本的执行计划放在一起逐字段对比，差异点就是故障的根源。

2、单独看某一个执行计划的字段值，很多时候你根本无法判断它是否合理，比如type字段为range，单独看这个值是符合预期的，但如果历史正常版本的type是ref，那这个变化就意味着优化器选择了代价更高的扫描方式，性能必然出现了明显的下降。

3、Explain对比的核心不是只看索引相关的字段，而是要覆盖从扫描类型、关联顺序、行数预估到额外信息的全链路字段，很多隐蔽的故障根本不会体现在索引字段上，而是藏在rows、filtered、Extra这些容易被忽略的字段里。

我们用这家本地生活平台的270万条消费券核销表作为测试样本，故障发生时的执行计划和正常版本的执行计划，单看索引字段你很难发现问题，但是把所有字段放在一起对比，12分钟就定位到了索引失效的根因，比传统的排查效率提升了10倍以上。

</