开启innodb_adaptive_hash_index会加剧latch争用，因其哈希操作需获取b+树页的btr_search_latch，导致同页多键查询串行化；页热点、高并发点查、缓冲池不足等场景下问题最显著，关闭可降30%~60% latch等待。
innodb_adaptive_hash_index 开启时，确实会显著增加 latch（页级轻量锁）争用，尤其在高并发点查场景下。这不是“锁变多了”，而是哈希索引的内部同步机制放大了原本就存在的竞争热点。
为什么AHI会导致latch锁激增？
AHI不是独立结构，它依附于Buffer Pool中的索引页，所有哈希桶操作（插入、查找、删除）都必须先获取对应B+树页的 buf_block_t::lock（即 btr_search_latch），才能安全访问或更新哈希表条目。
这意味着：哪怕两个查询命中的是不同主键值，只要它们落在同一个索引页（例如同一叶子页上的多条记录），就会因争夺该页的 btr_search_latch 而串行化——这是 latch 等待飙升的根源。
- 哈希索引本身不解决并发，反而把原本分散在B+树多层遍历中的锁竞争，集中到了少数热点页的 latch 上
- 当
innodb_buffer_pool_size不足、页淘汰频繁时，AHI重建触发更多 latch 操作，进一步恶化争用 -
SHOW ENGINE INNODB STATUS中的Hash table size行后若持续出现大量node heap has X buffer(s)，说明哈希节点正在高频分配/释放，伴随 latch 活动
哪些查询模式会让AHI的latch问题暴露得最明显？
不是所有等值查询都会触发严重 latch 争用，关键看是否形成「页级热点」：
- 主键或唯一索引上，
WHERE id IN (1,2,3,...)这类连续ID查询——极易集中在同一B+树叶子页 - 二级索引等值查询返回大量行（如
WHERE status = 'active'且该值高度重复），导致多个键映射到同一页 - 高并发短连接反复执行相同点查（如微服务中按用户ID查配置），缓冲池未充分预热，AHI反复构建/失效
此时 SHOW GLOBAL STATUS LIKE 'Innodb_buffer_pool_wait_free' 和 Innodb_mutex_spin_waits 通常也会同步升高，印证底层资源争用。
关闭AHI真能缓解latch压力吗？
能，但效果取决于实际负载特征：
- 若压测中
latch等待时间占总响应时间 >15%，且innodb_adaptive_hash_index = ON时SHOW ENGINE INNODB STATUS显示哈希表活跃度高（Hash table size数值大 + 多行node heap计数非零），关闭后 latch 等待常下降 30%~60% - 但若业务以范围查询为主（
BETWEEN、ORDER BY、LIMIT），AHI本就几乎不生效，关闭后性能无变化，也看不出 latch 改善 - 注意：关闭需全局生效（
SET GLOBAL innodb_adaptive_hash_index = OFF），且不会立即清空现有哈希表——它会随页老化自然释放
比开关更精细的应对方式
直接关AHI是粗粒度方案。更稳的做法是结合监控做条件性控制：
- 用
performance_schema抓取events_waits_history_long中等待事件为wait/synch/mutex/innodb/buf_block_mutex或wait/synch/rwlock/innodb/btr_search_latch的堆栈，定位具体SQL和页号 - 对确认为页热点的索引，考虑拆分逻辑（如加随机盐、分库分表）或调整
innodb_page_size（仅限新建实例）来降低单页密度 - MySQL 8.0+ 可配合
innodb_adaptive_hash_index_parts（默认为8）将哈希表拆分为多个分区，分散 latch 争用——但需确保innodb_buffer_pool_instances配置合理，否则可能引入新瓶颈
真正难处理的从来不是AHI开或关，而是它把隐性的页级访问模式暴露成了显性的 latch 热点——你得顺着这个线索，去查到底是哪几个页、哪几类查询在反复碰撞。
