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

【背景】线上 MySQL 8.0 主从架构，业务高峰时段出现慢查询 P99 抖动放大 20 倍的异常，通过 performance_schema 的 events_waits_history 表抓包发现部分查询耗时突然激增。

【现象】

1. 慢查询日志显示单条查询耗时从 10ms 突然飙到 200ms
2. performance_schema 的 events_waits_history 表中，单条查询的等待事件总和与实际耗时存在 30% 误差
3. 通过 SHOW ENGINE INNODB STATUS 分析发现 Buffer Pool 等待时间占比从 15% 突增至 65%

【已尝试】

• 开启 performance_schema 的 detailed_wait_class 选项
• 使用 perfmon 模板监控 CPU/IO/锁等待
• 通过 pt-query-digest 分析慢查询模式
• 检查 MySQL 配置文件中 performance_schema 的配置项

【期望答案】

1. performance_schema 如何将单条查询的等待事件拆分为 Buffer Pool IO、锁等待、CPU 等维度？
2. 为什么会出现等待事件总和与实际耗时的偏差？
3. 有哪些工具/方法能更精确地分解单条查询的耗时构成？

【引用】

1. 《连接池不是越大越好：一次 P99 抖动的排查与调参》(id=18)
2. 《Kafka 慢消费者停机 8 天，重启后静默跳过 465 万条：offsets.retention 默认 7 天与 auto.offset.reset 的丢消息窗口》(id=1530)
3. 《超时与重试：高并发后端最容易翻车、却最少被认真讨论的两件事》(id=23)