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 的乘积里，而不是单看哪个数字最大；一次分析后不做索引调整或驱动表干预，等于白看。
