【MySQL InnoDB 内核】性能调查：EXPLAIN ANALYZE 到 OS 层
内容提要
本文介绍MySQL性能调查的分层方法：从EXPLAIN ANALYZE查看计划实际耗时，到performance_schema分析等待事件，再结合InnoDB STATUS与OS层iostat/perf验证IO瓶颈。强调先查计划、再查等待、最后查IO，避免直接调参，并对比了PostgreSQL的对应工具，提供系统化排查思路。
延伸解读
分层排查避免盲目调参
文章强调性能调查应遵循“先计划、再等待、最后IO”的顺序，避免直接调整参数。这种分层方法有助于定位问题根源，例如区分是锁等待还是IO瓶颈。通过EXPLAIN ANALYZE查看实际执行时间，再结合performance_schema的等待事件，最后用iostat/perf验证OS层，能更精准地找到症结，减少无效调优。
工具版本与交叉验证
EXPLAIN ANALYZE需要MySQL 8.0.18及以上版本，使用时需注意版本兼容性。文章建议将performance_schema与InnoDB STATUS交叉验证，避免单一数据源误导。例如，Innodb_data_pending_writes和innodb_os_log_written速率可反映写压力，而PFS的IO等待事件则提供更细粒度信息，两者结合能更全面评估IO状况。
与PostgreSQL的对比启示
文章将MySQL与PostgreSQL的排查工具进行对照，显示两者分层思路一致：计划→等待事件→存储→OS。MySQL使用PFS events，PG使用pg_stat_activity.wait_event；IO层面MySQL用InnoDB STATUS/PFS，PG用pg_stat_io。这种对比有助于理解不同数据库在性能诊断上的共性，迁移经验时可参考对应工具。
Q&A
MySQL 性能调查中，EXPLAIN ANALYZE 的作用是什么？
EXPLAIN ANALYZE 是 MySQL 8.0.18+ 提供的工具，它可以在查询计划节点上显示实际执行时间（actual time），帮助定位延迟是发生在回表还是索引范围扫描等环节。它比慢查询日志更详细，能区分等锁和等 IO 等不同等待。
如何调查 MySQL 中的锁等待问题？
可以通过查询 performance_schema.data_lock_waits 表，结合 information_schema.innodb_trx 表，找出等待事务和阻塞事务的对应关系。具体 SQL 需要根据本地列名调整。
MySQL 中如何判断是否存在 IO 瓶颈？
可以通过 performance_schema 中的 wait/io/file/innodb/% 事件查看文件 IO 等待，同时关注 Innodb_data_pending_writes 和 innodb_os_log_written 速率等指标。在 OS 层使用 iostat -x 查看 %util 和 await 来验证磁盘是否饱和。
MySQL 性能调查中，如何分析 CPU 和 mutex 问题？
可以使用 performance_schema 的 events_waits_summary_global_by_event_name 表，过滤 mutex/innodb 相关事件，来查看 mutex 等待情况，从而分析 CPU 和锁竞争问题。
MySQL 性能调查的分层方法是什么？
分层方法为：先使用 EXPLAIN ANALYZE 查看查询计划的实际耗时，然后通过 performance_schema 分析等待事件，再结合 InnoDB STATUS 和 OS 层工具（如 iostat/perf）验证 IO 瓶颈。强调先查计划、再查等待、最后查 IO，避免直接调参。
MySQL 和 PostgreSQL 在性能调查工具上有哪些对应关系？
MySQL 的 EXPLAIN ANALYZE 对应 PG 的 EXPLAIN ANALYZE；MySQL 的 performance_schema events 对应 PG 的 pg_stat_activity.wait_event；MySQL 的 InnoDB STATUS / PFS 对应 PG 的 pg_stat_io；MySQL 的 perf + 符号对应 PG 的 perf + pg_stat。两者分层思路一致：计划 → 等待事件 → 存储 → OS。
