mysql 8.0 并未取消自增主键锁，而是将默认 innodb_autoinc_lock_mode 从1改为2，即启用交错模式：所有insert均不持表级auto_inc锁，改用预分配id段+轻量同步机制，在保证高并发性能的同时牺牲id连续性与statement复制安全性。
MySQL 8.0 并没有“取消”自增主键锁，而是把默认的锁行为从 innodb_autoinc_lock_mode=1 改为 innodb_autoinc_lock_mode=2——这本质是换了一种锁策略，不是去掉锁。
真正被移除的是“默认使用表级 AUTO-INC 锁”的保守模式；取而代之的是更激进、无锁分配的交错模式。它解决的不是“要不要锁”，而是“锁多宽、锁多久”。
innodb_autoinc_lock_mode=2 是什么，为什么它看起来像“没锁”
这个值代表“交错模式（Interleaved）”，核心特点是：
- 所有 INSERT（包括
INSERT SELECT、REPLACE、批量插入）都不再获取表级AUTO_INC锁 - 自增值预分配：每个并发 INSERT 会一次性向内存计数器申请一段 ID（比如 1001–1010），用完再申请
- 分配过程只依赖原子操作或轻量互斥量，不阻塞其他 INSERT
但要注意：
- 它不是“完全无锁”，只是锁粒度降到最低，不再阻塞语句执行
- 预分配段内未用完的 ID 就永久空洞（比如只插了 1 行，剩下 9 个 ID 就丢了）
- 在
binlog_format=STATEMENT下可能造成主从自增值不一致，所以 MySQL 8.0 强制要求binlog_format=ROW才允许设为 2
为什么 MySQL 8.0 要默认启用 innodb_autoinc_lock_mode=2
主要是为了应对现代高并发写入场景，尤其是：
- 微服务架构下大量短事务并发 INSERT
- 批量导入、ETL 任务频繁执行
INSERT SELECT - 云环境对吞吐和响应延迟更敏感
innodb_autoinc_lock_mode=1（旧默认）在批量插入时仍会加表锁，成为瓶颈；而 mode=2 把锁开销压到几乎为零，代价是牺牲 ID 连续性与部分复制确定性。
实际影响举例：
- 两个并发事务同时执行
INSERT INTO t SELECT ...，各自拿到不同 ID 段，互不等待 - 但如果其中一个事务回滚，它已预占的那段 ID 就彻底浪费，无法回收
切换后容易踩的坑
-
SELECT MAX(id)不再可靠：因为最大 ID 可能已被预占但未写入，或者已回滚 - 基于 ID 连续性做分页（
WHERE id > ? LIMIT N）逻辑可能漏数据或重复——这不是 bug，是设计使然 - 开发误以为“ID 连续 = 数据有序”，结果发现新插入记录的 ID 跳变很大，怀疑主键冲突或配置错误
- 从 MySQL 5.7 升级到 8.0 后，如果 binlog 格式仍是
STATEMENT，启动时会报错或自动降级为 mode=1，日志里出现警告：innodb_autoinc_lock_mode=2 requires binlog_format=ROW
真正的复杂点不在“有没有锁”，而在于：
mode=2 让自增行为变成不可预测的预分配 + 永久消耗，你没法靠观察插入顺序反推 ID 分配逻辑，也没法靠重启恢复“连续感”。业务如果强依赖 ID 的可推演性（比如导出序号、前端展示编号、审计流水号），就得主动放弃依赖，改用 UUID、雪花 ID 或业务侧生成序列。
