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

【背景】 MySQL 8.0.32 / InnoDB，单库 32C/128G，innodb_buffer_pool_size=48G。核心业务表 t_order 约 8000 万行，PK=id，联合索引 idx_user_status (user_id, status)。线上 2000+ QPS 的 OLTP 点查（按 user_id + status 查最近 10 条），日常 P50=3ms, P99=12ms。

【现象】 每天随机出现 2~5 次 P99 抖动：单条查询从 10ms 跳到 200~450ms，持续 3~8 秒后自动恢复。抖动期间：

• 慢日志记录 total_time=238ms，但没有子维度 breakdown；
• 全局 buffer pool 命中率从 99.4% 短暂掉到 97.8%（无法确认是这条查询触发的 miss）；
• 抖动窗口内 innodb_row_lock_waits 有 +3~5 增量，但没有锁等待告警。

【已尝试的排查】

1. performance_schema.events_statements_history_long：只记录 total_latency=238ms，无子维度拆分；
2. events_waits_summary_by_thread_by_event_name：抖动窗口内 row_lock 等待 avg 0.4ms / max 12ms，disk IO wait avg 0.1ms——看起来都不是主因；
3. sys.statements_with_runtimes_in_95th_percentile：能确认是那条 SQL，但没有 IO/CPU 细分；
4. 排除统计信息漂移：抖动窗口内 information_schema.tables 的 TABLE_ROWS 无变化，EXPLAIN 计划未切换（参考 id=208 的排查思路）；
5. SHOW ENGINE INNODB STATUS：HISTORY LIST 从 120 涨到 600，无锁冲突记录；
6. vmstat：抖动窗口 context switch 从 800/s 涨到 4200/s，si/so 从 0 涨到 5~15/s。

【卡点】

• 全局 buffer pool 命中率掉了 1.6%，但不确定是这条查询 miss 还是其他并发查询污染了热页；
• context switch 涨了 5 倍，无法区分是 InnoDB 内部 latch 竞争还是 OS 调度；
• performance_schema 的 wait 事件粒度太粗，events_waits_history 只记录"等了一个 mutex"，不告诉我是哪个 latch、等了多少页；
• 现有工具（pt-query-digest、sys schema）都只给 total，不给"这 238ms 里 180ms 是 disk read、40ms 是 mutex spin、18ms 是 CPU 计算"的分解。

【期望得到的答案形态】

1. 有没有一套 systematized 的方法，能在单条查询粒度上把耗时拆到「Buffer Pool 磁盘 IO / InnoDB 内部锁与 latch / CPU 计算 / 网络回传」四个维度？请给具体的 performance_schema 表/事件 + 查询语句；
2. AHI（adaptive hash index）在并发批量写入后是否会产生短暂 latch 竞争，导致同时刻点查抖动？怎么验证和排除？
3. 你团队线上遇到类似"偶发 10~30 倍 P99 抖动"时，最终归因是什么、用的什么手段定位的？