innodb_autoinc_lock_mode = 1 在 insert select 场景下会持表级 auto-inc 锁，阻塞所有其他自增插入，直至语句执行完成；该行为与实际行数无关，仅由语句类型触发，且不依赖事务大小。
innodb_autoinc_lock_mode = 1 在 INSERT SELECT 场景下会持表级锁
MySQL 5.7 默认的 innodb_autoinc_lock_mode = 1 对 simple insert（如 INSERT INTO t VALUES (NULL, 'x')）用轻量互斥量，但对 INSERT INTO t SELECT ... 这类 bulk insert，仍会预估行数后一次性申请整段自增 ID 并持表级 AUTO-INC 锁，直到语句执行完成。
这意味着：即使只查出 10 行，其他连接的任何自增插入（哪怕单行）都会被阻塞，直到该 SELECT 插入结束。常见现象是 SHOW PROCESSLIST 中大量线程卡在 Waiting for auto-inc lock。
- 不依赖事务大小，只看语句类型：
INSERT ... SELECT、REPLACE INTO ... SELECT、LOAD DATA都触发 bulk 行为 -
INSERT ... ON DUPLICATE KEY UPDATE看似 simple，但有唯一索引冲突时内部可能退化为 bulk 路径 - 锁持有时间与实际执行耗时强相关——慢查询 + bulk insert = 长期阻塞
设成 innodb_autoinc_lock_mode = 2 不一定安全
innodb_autoinc_lock_mode = 2 确实能让所有插入都走轻量互斥量，彻底避免 AUTO-INC 表级锁，但有两个硬性前提缺一不可：
-
binlog_format必须是ROW：执行SELECT @@binlog_format确认，否则主从自增值会错乱 - 不能依赖自增 ID 连续性：比如用
id BETWEEN 1000 AND 1010拉取数据，mode=2下跳号会导致漏数据 - MySQL 5.7 中
mode=2+STATEMENT或MIXEDbinlog 是明确不支持的配置，主从复制可能失败
RR 隔离级别下 Gap Lock 会和自增锁叠加恶化阻塞
如果业务同时用了默认的 REPEATABLE READ 隔离级别，那除了自增锁，还可能叠加 Gap Lock —— 尤其是带范围条件的 UPDATE 或 SELECT FOR UPDATE，会锁住索引间隙，进一步阻塞后续插入。
典型组合瓶颈：UPDATE t SET status=2 WHERE created_at > '2026-06-01' 锁住间隙 → 后续 INSERT INTO t 因无法插入对应间隙而等待 → 再叠加上 INSERT SELECT 触发的 AUTO-INC 锁，形成双重阻塞链。
- 降级到
READ COMMITTED可禁用 Gap Lock，但需同步确认binlog_format = ROW，且业务能容忍幻读 - UNIQUE KEY 或 FOREIGN KEY 仍会在 RC 下隐式加间隙锁（防冲突），这点容易被忽略
升级 MySQL 8.0 并不自动解决自增锁问题
MySQL 8.0 改进了自增分配逻辑（如动态分批预分配、MDL 解耦），但这些优化不会在 5.7 配置迁移后自动生效。若只升级版本却不调参，innodb_autoinc_lock_mode 仍默认为 1，bulk insert 依然卡。
- 8.0 中必须显式设
innodb_autoinc_lock_mode = 2，且要求enforce_gtid_consistency = ON才真正安全 - 即便升级，批量插入语句本身没拆分（如仍用大范围
INSERT SELECT），锁等待压力只是转移而非消失 - 真正拖慢系统的，往往不是自增锁本身，而是它和 MDL 锁、行锁、binlog commit 等机制的连锁等待
binlog_format 就直接改 innodb_autoinc_lock_mode，或者以为切到 RC 就一劳永逸，却忽略了唯一键隐式锁和应用层“读-判-写”逻辑的兼容性。
