性能调查：EXPLAIN ANALYZE 到 OS 层

慢查询日志只给 已完成 语句的墙钟时间，无法区分 等锁 还是 等 IO。MySQL 8.0.18+ 的 EXPLAIN ANALYZE 在计划节点上挂 actual time；performance_schema 把 mutex、IO、锁 拆到事件。若两者显示 CPU 低、延迟高，应下沉 iostat/perf 看是不是磁盘或 fsync 队列。

方法论对照 PG 第 23 篇 与 PG 监控篇。

一、调查分层

flowchart TD
  Q[延迟/吞吐异常] --> EA[EXPLAIN ANALYZE]
  EA --> PFS[performance_schema waits]
  PFS --> INN[INNODB STATUS 段]
  INN --> OS[iostat / perf]

二、EXPLAIN ANALYZE

-- 需本地验证
EXPLAIN ANALYZE SELECT ...;

关注：actual time 在 回表 还是 索引范围；rows 估计偏差大时更新统计信息 ANALYZE TABLE。

三、等锁调查

SELECT r.trx_id waiting, b.trx_id blocking
FROM performance_schema.data_lock_waits w
JOIN information_schema.innodb_trx r ON ...
-- 完整 JOIN 需本地根据列名调整

对照 第 9 篇。

四、等 IO 调查

OS 层：iostat -x 看 %util 与 await。

五、CPU 与 mutex

PFS 汇总 events_waits_summary_global_by_event_name 过滤 mutex/innodb——对照 第 1 篇 线程模型。

六、关键要点

1. 先计划后等待再 IO，避免直接调参。
2. EXPLAIN ANALYZE 需 8.0.18+。
3. PFS 与 STATUS 交叉验证。
4. OS 层验证 fsync 饱和 与 第 12 篇 组提交。

十、PG 对照

分层思路一致：计划 → 等待事件 → 存储 → OS。

上一篇：经典故障模式

下一篇：主从切换与数据恢复

参考资料

源码（MySQL 8.0.36）

• storage/innobase/ — 引擎实现
• sql/binlog.cc, sql/handler.cc — Server 层交界

官方文档

• MySQL 8.0 Reference Manual, InnoDB / Replication / Backup

相关文章

• 系列索引
• PostgreSQL 内核系列