MySQL 8.0为什么取消了默认的自增主键锁？

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 或业务侧生成序列。