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 索引），近期出现 P99 延迟从 12ms 峰值抖动到 240ms，且通过 performance_schema 采集到的事件耗时总和与实际查询耗时存在偏差。

【已尝试】

1. 开启 performance_schema 的 events_waits_history 表，发现等待事件类型集中于 innodb_buffer_pool_wait_free、lock_wait、wait/io/file/read 和 wait/io/socket/read。
2. 用 EXPLAIN 分析执行计划，发现 95% 查询命中 idx_user_status 索引，但部分查询出现 filesort。
3. 检查 innodb_buffer_pool_hit_rate 约 98%，但监控发现偶发「Buffer Pool 未命中 + 锁等待」叠加。

【期望答案形态】

1. 具体配置：如何通过 performance_schema 的 events_waits_history_long 表，将单条查询的耗时拆分为 Buffer Pool IO、锁等待、CPU 时间三个维度？
2. 可复现步骤：
   • 用 SQL 语句过滤出某次慢查询的事件记录
   • 用 JOIN 拼接 Buffer Pool 相关等待时间
   • 用锁等待事件定位具体锁类型（如行锁/表锁）
3. 边界条件：当事件记录被轮询清理（events_waits_history_long 限制 1000 条）时，如何保证采样完整性？
4. 对比数据：给出某次抖动期间的拆分数据示例（如 240ms = 80ms Buffer Pool + 60ms 锁等待 + 100ms CPU）