EXPLAIN ANALYZE 是定位复杂联表查询真实性能瓶颈最有效的方式，因其真执行、真计时、真统计，能暴露预估不准、过滤低效、连接不合理及I/O过高等问题。
直接用 EXPLAIN ANALYZE 替代普通 EXPLAIN，是定位复杂联表查询真实性能瓶颈最有效的方式——它不只看“计划”，而是真执行、真计时、真统计。
为什么必须用 ANALYZE 而不是普通 EXPLAIN
普通 EXPLAIN 只展示优化器的预估计划：预估扫描多少行、选哪个索引、走什么连接顺序。但预估常不准，尤其在统计信息过期、数据倾斜或隐式类型转换时。比如某联表查询显示 rows=500，实际运行却扫描了 20 万行；又或者显示用了索引，但因排序字段未覆盖，仍触发 Using filesort，而耗时全在那一步——这些只有 ANALYZE 才能暴露。
EXPLAIN ANALYZE 的核心价值在于返回三类真实数据：
- Actual rows：每张表/每个步骤实际读取的行数（对比预估 rows，偏差大即统计失准）
- Execution time：每个操作节点的真实耗时（毫秒级），一眼看出哪步拖慢全局
- Loops：嵌套循环中内层表被重复访问的次数（如驱动表 1000 行 × 内表 50 次 = 实际执行 5 万次 join）
重点关注 ANALYZE 输出中的关键信号
执行后，逐行看输出，特别盯住带 "->" 缩进的子节点和末尾的 Summary 行：
- “Rows Removed by Filter” 高 → 条件过滤效率低：例如某表预估扫描 1 万行，实际只保留 200 行，说明 WHERE 条件没走索引或选择性差，应检查字段是否加索引、是否符合最左前缀
- “Actual time” 在 Nested Loop 或 Hash Join 节点上明显偏高：说明连接方式或驱动表选择不合理。比如小表没当驱动表，导致大表被反复扫描；或 ON 条件字段无索引，被迫做全量匹配
-
出现 “Materialize” 或 “Temporary Table” 且耗时长：对应普通 EXPLAIN 中的
Using temporary，常见于未索引的 GROUP BY / ORDER BY / DISTINCT，或子查询未被优化为 semi-join -
“Buffers” 显示大量 I/O（如
Read: 1248 disk）：说明数据不在 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'
-
第一步：加 ANALYZE 并执行
EXPLAIN ANALYZE 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'; -
第二步：从底向上读，找耗时最长的叶子节点
先看addresses表节点：若显示Actual time: 85.2..120.7 ms且Loops: 10240，说明它被驱动了上万次——问题大概率出在users或orders没控制好驱动结果集大小 -
第三步：验证驱动表合理性
检查users表节点的Actual rows。如果WHERE u.status = 'active'返回 5 万行，但orders表只有 2000 行，就该让orders当驱动表，改写为STRAIGHT_JOIN强制顺序，或给orders.created_at加索引缩小初始集 -
第四步：确认索引是否真正生效
看orders节点的Key Lookup和Index Condition Pushdown是否启用。若显示Index Cond: (created_at > '2026-03-01')但仍有大量Rows Removed by Filter，说明索引没覆盖user_id字段，应建复合索引(created_at, user_id)
配合使用的必要动作
单靠 ANALYZE 不够，还需同步做几件事：
-
更新统计信息：执行
ANALYZE TABLE users, orders, addresses;，避免优化器因旧统计误判 -
检查执行环境：确保
innodb_stats_persistent = ON且采样页数足够（innodb_stats_persistent_sample_pages建议 ≥ 100） - 对比不同写法：对同一逻辑尝试 LEFT JOIN 改 INNER JOIN、子查询改 JOIN、添加 LIMIT 等，用 ANALYZE 直接比耗时
-
关联系统指标：若 ANALYZE 显示某步 CPU 时间占比极高，查
SHOW PROCESSLIST看是否锁等待；若 I/O 时间高，结合iostat看磁盘负载
