一个常被忽略的关键事实：绝大多数MySQL性能问题，并非SQL语句写错，而是开发者根本不清楚慢查询究竟卡在哪个环节。
EXPLAIN ANALYZE是MySQL 8.0.18版本引入的实测型执行分析命令。它并非进行预判，而是真实执行一次SQL语句，然后精确报告每一阶段消耗的时间、处理的数据行数以及循环次数。相比之下，普通EXPLAIN仅仅基于统计信息进行预估，与实际执行结果往往存在巨大偏差——这正是许多慢查询无法定位根因的症结所在。
简而言之，EXPLAIN ANALYZE是唯一能够明确告知“哪一步真正慢、为什么慢、慢了多少”的工具——它不是猜测，而是实测。
为什么不能只依赖普通EXPLAIN？
普通 EXPLAIN 的输出看似清晰：例如它显示 rows=500，但实际执行时可能扫描了32万行；它显示使用了 key=idx_user_status，但由于 WHERE u.status = 'active' 后面还有 ORDER BY o.created_at DESC，而该索引并未覆盖排序字段，导致触发了 Using filesort——真正的耗时都消耗在此。诡异的是，EXPLAIN 对这类信息完全不会给出提示。
常见的问题场景包括：
- 虽然已经添加了索引，
EXPLAIN显示type=ref，但查询依然缓慢 → 实际原因可能是filtered值极低（比如0.5%），导致大量的回表操作 - 表连接顺序看似合理，但总体耗时却异常高 → 驱动表选错，内层表被循环扫描的次数（
Loops）远超预期，这才是真正的凶手 - 看到
Extra: Using temporary; Using filesort就盲目加索引 → 可EXPLAIN ANALYZE一跑，发现临时表本身只耗了2ms，真正卡住的是某张表的磁盘读（Read: 1842 disk）
如何解读EXPLAIN ANALYZE的关键字段？
执行 EXPLAIN ANALYZE SELECT ... 之后，应重点关注缩进结构中每行末尾的括号信息，以及Summary行中的内容：
actual time=0.042..198.631：该区间表示节点从启动到结束的毫秒耗时，差值即为纯执行时间。若某个Nested loop inner join节点耗时占总时间的92%，则说明连接逻辑或驱动表的选择需要重新优化Rows Removed by Filter: 99980：某张表预估扫描了10万行，实际仅保留200行 → 过滤条件未走索引，或字段选择性过低（比如gender只有 'M' 和 'F'）Loops=127：驱动表返回127行，内层表被反复访问了127次。若内层表缺少合适索引，相当于执行了127次全表扫描Buffers: shared hit=1248 read=42：read值高表示大量数据未命中buffer pool。应优先考虑增大innodb_buffer_pool_size，或设法减少扫描范围
三表联查时最容易踩的坑
举一个典型示例：SELECT u.name, o.total, a.city FROM users u JOIN orders o ON u.id = o.user_id JOIN addresses a ON u.id = a.user_id WHERE u.status = 'active' AND o.created_at > '2026-03-01'
这里有几点容易被忽视的注意事项：
- 不要想当然地认为
users是最佳驱动表。如果users中status='active'的比例高达95%，而orders上created_at > '2026-03-01'仅返回200行——那么应该以orders作为驱动表才更合理 addresses表若未在user_id上建立索引，EXPLAIN ANALYZE会清晰显示其actual time在Nested loop内部急剧上升，Loops值等于驱动表行数 × 1- 跨表添加WHERE条件需谨慎。例如加入
a.city = 'Shanghai'，MySQL 可能被迫放弃过滤下推，只能先连接两表再统一过滤。此时Rows Removed by Filter会出现在最外层的Filter节点，而非addresses的访问节点中
必须配合完成的两项操作
EXPLAIN ANALYZE 本身不会提升性能，它只是将问题清晰地呈现出来。但你必须执行以下两项操作，否则分析结果毫无意义：
- 对于
Rows Removed by Filter值较高的字段，使用SHOW INDEX FROM table_name确认索引是否包含该字段，并符合最左前缀原则；同时避免在VARCHAR字段上使用LIKE '%xxx'还期望走索引 - 对于高
Loops且高actual time的内层表访问，可以考虑手动强制驱动表顺序：在小表上使用STRAIGHT_JOIN，或将查询改写为子查询加JOIN的形式，再通过EXPLAIN ANALYZE对比执行结果
请记住：真正的性能瓶颈，往往隐藏在 actual time 与 Loops 的乘积中，而非单独看哪个数字最大。一次分析后如果不进行索引调整或驱动表优化，便等同于白费功夫。
