InnoDB AHI 把点查 P99 从 2ms 拉到 30ms：btr_search_latch 争用怎么定量确认，关掉 AHI 的代价怎么评估？

背景

MySQL 8.0.36（InnoDB，16C64G，buffer_pool 48G），核心表 t_order 约 2 亿行，主键 id（bigint 自增）。业务是高频点查 + 点更新（按 PK），QPS 约 8k，隔离级别 RC。

现象

1. P50 稳定在 1.2ms，但 P99 每 20~40s 周期性飙到 20~50ms，P999 偶发 80ms+；
2. 飙升窗口内 performance_schema.events_waits_summary_global_by_event_name 出现 wait/synch/cond/rw-lock/btr_search_latch（InnoDB AHI 内部 latch）等待量从正常的 <500 飙到 200k+；
3. SHOW STATUS LIKE 'Innodb_adaptive_hash%' 显示 hit rate ≈ 78%，看起来"健康"，但飙升时刻 Innodb_adaptive_hash_hits 增量反而下降、Innodb_adaptive_hash_misses 增量上升——怀疑是 AHI 在高频更新后触发内部 rebuild，rebuild 期间 latch 争用放大；
4. 业务侧表现：同一 SQL、同一行、同一并发量，P99 抖动完全不可预测，和业务流量无关（凌晨 3 点 QPS 只有 2k 时照样抖）。

已尝试

1. SET GLOBAL innodb_adaptive_hash_index=OFF → P99 立刻稳定到 3~5ms，但 P50 从 1.2ms 涨到 1.8ms（多走了一次 B-tree 查找的 I/O 路径），整体吞吐降约 8%；
2. SET GLOBAL innodb_adaptive_hash_index_parts=32（默认 8）→ P99 峰值从 50ms 降到 35ms，P50 基本不变，但没有根治，还是周期性抖；
3. 调 innodb_buffer_pool_instances 从 8 到 16 → 无显著变化；
4. 查了 SHOW ENGINE INNODB STATUS 的 ADAPTIVE HASH INDEX 段：hash table size 约 4M entries，number of buckets 随 parts 变化，但没有暴露 rebuild 次数或 latch 等待时长分布；
5. 用 perf record -g -p <mysqld_pid> 抓了 30s 火焰图：飙升窗口内 btr_search → btr_search_latch_wait 占比从 2% 涨到 18%，确认是 AHI 内部争用而非 buffer pool 的 buf_LRU_list_mutex。

期望得到的答案形态

1. 定量确认 AHI latch 争用是根因的方法：除了 perf 火焰图，有没有更轻量的手段（比如 performance_schema 里哪些表/事件能直接量化 btr_search_latch 的等待分布）？Innodb_adaptive_hash_hits/misses 在 rebuild 期间的行为有没有文档化的解释？
2. AHI 开/关的代价评估框架：我现在的结论是"关了 P99 稳但 P50 涨、吞吐降 8%"——这个取舍有没有更精细的调法？比如按表/按查询类型选择性启用 AHI（我知道 InnoDB 不支持，但有没有变通方案，比如把热点 PK 范围单独建一个内存表）？
3. innodb_adaptive_hash_index_parts 的调优边界：parts 越大 latch 争用越小，但每个 part 的 hash table 越小、miss 率越高——这个 tradeoff 的"最优点"有没有经验公式或压测方法？我试了 8/16/32/64，32 最好但 64 反而 P50 又涨了，想理解背后的机制。
4. 监控告警：如果最终决定"保持 AHI ON + parts=32 + 接受 35ms 的 P99 峰值"，我该监控哪个指标来提前预警 AHI 劣化（比如 latch 等待 P99 > X ms 持续 N 秒就告警）？

补充

• 我读过站内关于 EXPLAIN rows 估算偏差的文章（id=1859），那个场景是统计信息采样导致优化器选错索引；我这里是索引命中了、执行计划没变，纯粹是 InnoDB 引擎层 AHI 的 latch 争用——想确认我的判断是否正确，以及有没有遗漏的其他引擎层原因。
• 版本：MySQL 8.0.36，InnoDB，innodb_flush_log_at_trx_commit=1，sync_binlog=1，隔离级别 READ COMMITTED。