innodb_autoinc_lock_mode 是控制 innodb 自增列批量插入加锁范围与持续时间的参数，默认值 1（连续模式）兼顾安全与性能；设为 0 会导致全表锁、性能差，设为 2 则要求 binlog_format 必须为 row，否则主从不一致。
innodb_autoinc_lock_mode 是什么，为什么改它会出问题
这个配置控制 MySQL InnoDB 对 AUTO_INCREMENT 列在批量插入时加锁的策略，不是“要不要锁”，而是“锁多宽、锁多久”。默认值 1（连续锁模式）在大多数业务里够用，但一换到 0 或 2，就可能遇到主从不一致、自增值跳变、甚至插入卡住——尤其当有 INSERT ... SELECT、REPLACE 或触发器参与时。
三种取值的实际行为差异
别只看文档里的“传统/连续/交错”这种词，重点看它怎么影响你的 SQL：
-
0（传统模式）：所有带AUTO_INCREMENT的 INSERT 都用表级LOCK TABLES WRITE，串行执行。安全但慢，高并发插入明显瓶颈，已不推荐 -
1（默认，连续模式）：普通 INSERT（值确定长度）预分配连续 ID，不锁表；但INSERT ... SELECT、LOAD DATA这类“不确定行数”的语句仍会持锁直到语句结束——这是主从延迟或死锁的常见源头 -
2（交错模式）：所有情况都只做轻量级 mutex，不持表锁，ID 可能不连续（如事务回滚后空缺），且**主从复制必须用 ROW 格式**，否则从库自增错乱
修改前必须检查的三件事
直接改 innodb_autoinc_lock_mode 而不验证，等于给自增列埋雷：
- 确认 binlog_format 是
ROW：如果还是MIXED或STATEMENT，切到2后从库大概率写入失败，报错类似Cannot execute statement: binlog format is not ROW - 查有没有
INSERT ... SELECT或存储过程批量写入：这类语句在1下会锁较久，在2下虽快但 ID 不保序，业务若依赖“自增 ID 递增即时间先后”，就得重设计 - 检查监控里是否有
Innodb_row_lock_waits突增：如果当前锁等待已高，调低 lock_mode 可能缓解，但也可能因 ID 分配冲突引发更多重试
线上环境怎么安全调整
这不是改完配置 reload 就完事的操作：
- 先在从库上设
SET GLOBAL innodb_autoinc_lock_mode = 2（不影响主库），观察 1–2 天复制延迟和错误日志 - 确认无
Unsafe statement告警、无Duplicate entry for key 'PRIMARY'类报错（说明自增没撞车） - 再改主库，且必须配合
SET GLOBAL binlog_format = 'ROW'（如果还没切） - 重启不是必须的，但
mysqld启动参数里写的值优先级高于运行时 SET，记得同步更新配置文件中的innodb_autoinc_lock_mode
真正麻烦的从来不是改哪个数字，而是你系统里那些没显式写 INSERT 却偷偷调用自增逻辑的地方——比如 ORM 的 save()、框架的批量 create、甚至某个被遗忘的事件触发器。
