explain analyze 会真实执行sql并返回实测数据，而explain仅做优化器预估；前者显示actual time、loops等运行时指标，后者仅输出预估rows和type等统计值。

EXPLAIN ANALYZE 和 EXPLAIN 有什么本质区别

关键就一条：EXPLAIN ANALYZE 会真实执行 SQL，而 EXPLAIN 只做预估。前者返回的是“实测数据”，后者是优化器拍脑袋算出来的统计值。

比如你看到 EXPLAIN 的 rows=1000，但实际可能扫了 50 万行；而 EXPLAIN ANALYZE 里 rows = 498231、loops = 1，你就知道这一步真干了快 50 万次 I/O。

• actual time 格式是 start..end，总耗时 = end - start，单位毫秒
• loops 很容易被忽略：嵌套循环里，外层查出 N 行，内层就执行 N 次，总成本 = actual time × loops
• MySQL 版本必须 ≥ 8.0.18，低于这个版本直接报错 Unknown syntax

怎么一眼看出哪步最拖慢查询

别看第一行，要看“子操作”的累计开销。尤其是 Nested Loop Inner Join 下面的 Index Lookup 或 Table Scan 行，它们的 actual time × loops 常常占整条 SQL 总耗时 90% 以上。

MySQL

编写正确的MySQL查询，避免字符集、索引和锁方面的常见陷阱。

下载

• 如果某行 loops = 5000 且 actual time = 0.02..0.15，那它实际贡献了约 0.13 × 5000 ≈ 650ms
• Table scan on users 出现且 rows 很大，说明没走索引，优先加索引或改 WHERE 条件
• Index Range Scan 的 rows 和 loops 都高，可能是范围条件太宽（如 create_time > '2020-01-01'），需要收紧或加时间分区

常见陷阱：为什么 ANALYZE 结果看起来“更差”

不是查询变慢了，是你第一次看清了它本来有多慢。很多开发者用完 EXPLAIN ANALYZE 后才意识到：原来那个“还好”的查询，实际在生产环境每秒都在吃掉 200ms CPU。

• 缓存干扰：首次运行 EXPLAIN ANALYZE 时，数据可能不在 buffer pool，第二次跑会快很多 —— 所以建议清空缓存后多跑几次取平均值：RESET QUERY CACHE;（旧版）或 FLUSH TABLES; + 关闭 query_cache_type
• 写操作阻塞：如果 SQL 包含 UPDATE 或锁表动作，ANALYZE 会真实加锁，影响其他连接 —— 切勿在高峰期对核心表直接跑
• filtered 字段在 ANALYZE 输出里不显示，但它的缺失会让优化器误判选择性；若发现 rows 远大于实际结果数，大概率是 WHERE 条件中用了函数（如 YEAR(create_time) = 2025）导致索引失效

什么时候该停手，转去建索引或改 SQL

当看到以下任意一种组合，基本不用再调参，立刻建索引或重构逻辑：

• type = ALL 且 rows > 10000（全表扫描超万行）
• Extra 出现 Using filesort 或 Using temporary，同时 rows × loops > 50000
• Index Lookup 的 loops 等于外层 Index Scan 的 rows，但内层 rows 是 1 —— 这说明驱动表选错了，应交换 JOIN 顺序或强制 STRAIGHT_JOIN
• 复合条件中，只有前导列命中索引（如索引是 (a,b,c)，但 WHERE 只有 b = ? AND c = ?），key_len 显示为 0，key 为 NULL

真正难的不是看懂 EXPLAIN ANALYZE，而是判断哪一行的 loops 是设计使然、哪一行是索引没覆盖到位。这个分寸，得在慢日志 + ANALYZE + 实际数据分布之间来回比对才能拿准。