SQL执行计划如何分析_真实案例解析强化复杂查询思维【教程】

SQL 执行计划是数据库优化核心，需结合数据分布、连接方式等分析；关键看 filtered、Extra、key_len 三字段；连接顺序由优化器决定；GROUP BY/ORDER BY 需索引覆盖；优化案例显示索引调整与条件精炼可将 8 秒查询降至 0.3 秒。

SQL 执行计划是数据库优化的核心入口，看懂它，才能真正定位慢查询的根源。不是简单扫一眼“全表扫描”就加索引，而是要结合数据分布、连接方式、过滤条件和执行顺序，还原数据库实际做了什么。

读懂执行计划的关键列：不要只盯 type 和 rows

MySQL 的 EXPLAIN 输出里，type（访问类型）、rows（预估扫描行数）、key（实际用到的索引）常被关注，但容易忽略三个更关键的字段：

• filtered：表示该表经过 WHERE 条件过滤后，剩余行数占扫描行数的百分比。比如 rows=10000，filtered=10.00，说明只留下约 1000 行——这提示你的条件选择性差，可能需要调整索引顺序或补充条件
• Extra中的 Using index condition（ICP）代表索引下推，是好事；但出现Using filesort 或Using temporary就要警惕，意味着排序 / 分组没走索引，可能触发磁盘临时表
• key_len能反推索引用了几个字段及是否用到最左前缀。例如索引是 (a,b,c)，key_len=767（假设 a 是 VARCHAR(255) utf8mb4），说明只用到了 a；若 key_len=767+5=772，大概率 a 和 b 都参与了查找

连接顺序不是 SQL 写的顺序，而是优化器选的

很多人以为 SELECT * FROM A JOIN B ON …… JOIN C ON …… 就是按 A→B→C 执行，其实不一定。优化器会基于统计信息重排驱动表。真实案例中曾遇到：

三表关联：orders（百万级）、order_items（千万级）、products（万级）。SQL 写的是 orders JOIN order_items JOIN products，但 EXPLAIN 显示驱动表是products（小表），接着嵌套循环到order_items，最后才到orders——因为products.id 有高选择性过滤条件，且 order_items.product_id 上有索引，优化器判断这样成本更低。

如果你发现小表没当驱动表，或大表被反复嵌套扫描，检查：
– 关联字段是否有索引（尤其被驱动表的 ON 字段）
– WHERE 条件是否落在驱动表上（让优化器有理由优先选它）
– 是否存在 隐式类型转换（如字符串字段与数字比较），导致索引失效、驱动表误判

聚合与排序：GROUP BY 和 ORDER BY 不是“顺带完成”的

执行计划里一旦出现 Using filesort 或Using temporary，基本等于告诉你要优化了。重点看两点：

• GROUP BY 字段是否包含在索引最左部分？例如 GROUP BY status, created_at，索引建为(status, created_at) 可覆盖；若只建(created_at)，就无法避免临时表
• ORDER BY 和 GROUP BY 字段顺序不一致？比如GROUP BY a,b ORDER BY b,a，即使两个字段都有索引，也大概率触发 filesort——因为索引有序性无法同时满足两种排序逻辑
• 用 SELECT * 做分组？会导致临时表存大量冗余字段。应只 SELECT GROUP BY 字段 +聚合函数，必要时用子查询或 CTE 先聚合再 JOIN 补字段

真实问题现场：一个看似简单却跑了 8 秒的报表 SQL

原始语句：

SELECT o.status, COUNT(*)<br>  FROM orders o<br>  JOIN order_items i ON o.id = i.order_id<br>  WHERE o.created_at > '2024-01-01'<br>    AND i.sku LIKE 'ABC%'<br>  GROUP BY o.status;

EXPLAIN 发现：
– orders走了 created_at 索引（type=range），rows=12 万，但 filtered=1.2（条件太宽）
– order_items 是ALL（全表扫描），rows=800 万，Extra 里全是Using where; Using join buffer
– 最终临时表排序耗时占 70%

优化动作：
– 给 order_items(order_id, sku) 建联合索引（让 JOIN + LIKE 都能走索引下推）
– 把 o.created_at > '2024-01-01' 换成更精确的范围，或加状态前置过滤（如AND o.status IN ('paid','shipped')）提升 filtered 值
– 改写为先查出符合条件的 order_id 列表（覆盖索引），再 JOIN 聚合，避免大表嵌套

优化后执行时间降至 0.3 秒，执行计划中不再出现 Using temporary 和Using filesort。

基本上就这些。执行计划不是终点，而是你和数据库对话的开始——它说的每句话，都在告诉你“我 为什么 这么干”。多看几次真实慢查的计划，比背一百条优化口诀管用。