MySQL 8.0 支持安全启用 innodb_autoinc_lock_mode=2，因其强制要求 binlog_format=ROW 且 enforce_gtid_consistency=ON，避免主从 ID 冲突；而 MySQL 5.7 缺乏该校验，开启 mode=2 易导致复制不一致。
innodb_autoinc_lock_mode=2为什么在MySQL 8.0里能用，5.7里不敢开？
因为 MySQL 8.0 在 innodb_autoinc_lock_mode=2 下加了两道安全锁：必须 binlog_format = ROW 且 enforce_gtid_consistency = ON，否则启动时直接报错。而 MySQL 5.7 没这层校验，设成 2 后主从可能因 binlog 执行顺序和实际分配顺序不一致，导致从库 ID 冲突或跳号错乱。
所以不是“8.0 更先进”，而是它把原本靠 DBA 经验兜底的配置，变成了启动期强制检查项。线上切 mode=2 前，务必确认：
-
SELECT @@binlog_format返回ROW -
SELECT @@enforce_gtid_consistency返回ON - 所有从库已同步开启 GTID（
gtid_mode = ON）
INSERT ... SELECT 还是卡？mode=2没用，正常
innodb_autoinc_lock_mode=2 只对简单 INSERT（如 INSERT INTO t VALUES (1),(2)）生效，对 INSERT ... SELECT、REPLACE ... SELECT、LOAD DATA 这类语句，InnoDB 仍会按需加 AUTO-INC 表级锁——这是设计使然，不是配置漏了。
真要解这个卡点，得换写法：
- 把大范围
INSERT INTO t SELECT * FROM s拆成带WHERE id BETWEEN ? AND ?的小批次，每次不超过 500 行 - 避免在子查询里用
ORDER BY RAND()或复杂 JOIN，这类操作会让预估行数失准，触发更保守的锁策略 - 监控
Innodb_autoinc_readiness_wait状态变量，值持续 > 10ms 就说明自增就绪等待成了瓶颈
为什么关了自增锁，INSERT ON DUPLICATE KEY UPDATE反而更慢？
因为 INSERT ... ON DUPLICATE KEY UPDATE 的执行路径本质是“先查再插再更新”，哪怕开了 mode=2，它仍要对唯一键对应记录加 X 锁 + insert intention 锁。如果多个线程反复撞同一个唯一键（比如都用手机号去 upsert），就会在那条记录上形成锁队列，后面请求全堵住。
这不是自增锁的问题，是业务逻辑和索引设计问题：
- 别拿低基数字段（如
status、type）建 UNIQUE 索引，区分度太低，容易聚集冲突 - 高频 upsert 场景优先用
INSERT IGNORE，失败就重试，比 update 更轻量 - 实在要用 upsert，确保唯一键字段本身足够离散（比如用户 ID、订单号），而不是状态位
重启后参数失效？my.cnf里写了也不生效？
SET GLOBAL innodb_autoinc_lock_mode = 2 只影响新连接，旧连接继续用旧值；而且 MySQL 重启后会读配置文件重载，但如果你改的是错误路径下的文件（比如改了 /etc/my.cnf，实际加载的是 /etc/mysql/mysql.conf.d/mysqld.cnf），或者没加 [mysqld] 段落头，参数根本不会被加载。
确认是否生效的硬办法：
- 查运行时值：
SELECT @@innodb_autoinc_lock_mode - 查配置源：
SELECT VARIABLE_NAME, VARIABLE_SOURCE FROM performance_schema.variables_info WHERE VARIABLE_NAME = 'innodb_autoinc_lock_mode'，返回CONFIG才算真正从文件加载 - 别忘了从库也要同步改配置并滚动重启，主从不一致会导致复制中断
真正难的不是调参数，是判断哪条 SQL 正在争抢自增锁、哪条又在争抢行锁、哪条其实在等 MDL——三者混在一起时，光调 innodb_autoinc_lock_mode 解不了全部问题。
