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，基本等于告诉你要优化了。重点看两点：

Notion Sites

Notion 推出的AI网站构建工具，允许用户将 Notion 页面直接发布为完整网站。

246

查看详情

• 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。

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