MySQL 8.0 慢查询 P99 偶发抖动 20 倍：performance_schema 怎么把单条查询耗时拆到 Buffer Pool IO / 锁 / CPU 三个维度？

【核心原理】 MySQL 8.0 的 performance_schema 通过 events_waits_history_long 表记录等待事件，结合 sys.schema 视图可拆解三维度：

1. Buffer Pool IO：分析 sys.io_waits_by_table 看磁盘读取延迟，若 t_order 表出现大量 'innodb_buffer_pool_read_requests' 等待，需检查缓冲池大小或索引效率；
2. 锁竞争：通过 sys.schema_lock_waits 查看锁等待队列，若 'lock_wait' 事件占比高，需优化事务隔离级别或索引设计；
3. CPU 计算：观察 sys.session 中 'wait/total' 指标，若 CPU 利用率突增，需排查查询复杂度或连接池配置。

【关键配置】

1. 开启 performance_schema 的 events_waits_history_long 表，设置 performance_schema_max_table_handles=20000；
2. 启用 sys schema 的 sys.session 和 sys.io_waits_by_table 视图；
3. 使用 EXPLAIN 分析慢查询执行计划，重点检查是否命中索引（type=ref/range）。

【调优案例】 某金融系统通过该方法发现 t_order 表的 'idx_user_status' 索引碎片化导致随机IO飙升，重建索引后 P99 延迟从 240ms 降至 12ms。