innodb_autoinc_lock_mode=2通过预分配id段消除简单insert的auto_inc表锁，显著减少高并发插入时的锁等待；但要求binlog_format=row且id不连续，且对insert select等语句无效。
MySQL 8.0 的自增主键缓存机制本身不直接“提升索引插入效率”，它解决的是 AUTO_INCREMENT 值分配阶段的锁竞争问题——而这个阶段恰恰是高并发插入时最常卡住的地方。真正受益的是写入吞吐量，不是索引结构本身。
innodb_autoinc_lock_mode=2 为什么能减少锁等待
在 innodb_autoinc_lock_mode = 2（交错模式）下，简单 INSERT 不再需要持有 AUTO-INC 表级锁，而是由 InnoDB 维护一个内存中的“自增缓存区间”（比如预分配 1–1000），每个插入线程从中快速取走一段连续 ID，互不阻塞。
- 对比
innodb_autoinc_lock_mode = 1（默认）：每次简单插入仍需短暂加锁，虽比 mode 0 轻量，但在每秒数千次插入时仍可见排队 - mode 2 下，只要缓存没耗尽，
INSERT INTO t (a,b) VALUES (1,2)这类语句完全无锁分配 ID - 注意：含
INSERT ... SELECT或REPLACE的语句仍会触发表级锁，mode 2 不对其生效
缓存机制和聚簇索引写入的关系
自增 ID 分配快了，只是第一步；真正影响索引效率的是新行是否能“顺序追加”到 B+ 树叶子页末尾。而缓存机制间接保障了这一点：
- 自增 ID 保持大致递增（即使有空洞），避免了随机跳号导致数据物理位置散乱
- 新记录持续写入索引最右侧页，减少页分裂、降低磁盘随机 I/O
- 如果用
UUID或打乱顺序的BIGINT，哪怕分配再快，也会因写入位置跳跃造成频繁页分裂和缓冲池失效
容易被忽略的两个实际限制
缓存机制不是万能的，以下情况会让它失效或引入新问题：
- 服务器异常重启后，缓存中未持久化的 ID 段会丢失，但 MySQL 8.0 会从磁盘恢复最大 ID 值（通过系统表
mysql.innodb_table_stats或 redo log），所以不会重复，但可能跳号更大 - 事务回滚时已分配的 ID 不回收——这是设计使然，不是 bug。例如插入 10 条后回滚，下一个 ID 是 11，不是 1
-
innodb_autoinc_lock_mode是全局参数，不能按表设置；若业务混合了批量导入（需强连续性）和高并发 API 写入，需权衡取舍
真正卡住插入性能的，往往不是磁盘或 CPU，而是 ID 分配环节的锁排队和后续索引页的争抢。把 innodb_autoinc_lock_mode 调对、主键类型选稳、避免非递增写入，这三件事做扎实，比调 buffer pool 大小见效更快。
