innodb_autoinc_lock_mode=2可提升并发性能，但必须确保binlog_format=row，否则主从不一致；默认mode=1在insert select等批量操作时仍持表级锁至语句结束，导致高并发写入阻塞。
直接设 innodb_autoinc_lock_mode = 2，但必须确认 binlog_format = 'ROW'，否则主从不一致；这不是“开个开关就提速”，而是换锁行为——用 ID 不连续换掉锁等待。
为什么默认 mode=1 在高并发 INSERT 时卡住
默认值 1（“连续模式”）对 INSERT SELECT、REPLACE INTO ... SELECT、LOAD DATA INFILE 这类批量语句，仍会全程持有表级 AUTO_INC 锁，直到语句执行完。哪怕只是插入 1000 行，其他所有并发 INSERT 都得排队等它释放锁。
- 现象：
SHOW PROCESSLIST里大量线程卡在Waiting for table level lock，CPU 被innodb_autoinc_lock相关函数吃满 - 不是慢查询，是锁阻塞：慢日志里
INSERT耗时突增，但EXPLAIN显示执行计划正常 - 只影响写入路径：读操作完全不受影响，所以监控里可能只看到写 QPS 上不去、复制延迟飙升
mode=2 真正生效的条件和边界
innodb_autoinc_lock_mode = 2 并非对所有 INSERT 都无锁。它只对 Simple inserts（如 INSERT INTO t VALUES ()）彻底跳过 AUTO_INC 锁；Bulk 和 Mixed-mode 插入仍会退化为语句级锁。
- 能无锁的：单行或明确多值
INSERT INTO t (a,b) VALUES (1,2), (3,4), (5,6) - 仍要锁的：
INSERT INTO t SELECT * FROM tmp、REPLACE INTO t SELECT ...、INSERT INTO t VALUES (100,'x'), (NULL,'y')（混合显式/隐式自增） - 必须同步检查：
SELECT @@binlog_format必须返回ROW；否则主库分配了 ID，从库重放时可能错乱 - 立即生效但不持久：
SET GLOBAL innodb_autoinc_lock_mode = 2需 SUPER 权限，重启失效，必须写进my.cnf的[mysqld]段
开了 mode=2 后发现 ID 跳变，是不是出错了
不是错误，是设计行为。mode=2 下 InnoDB 采用预分配机制：事务启动时就向自增计数器“批取”一段 ID（比如一次拿 32 或 64 个），即使事务回滚，这些 ID 也不会回收。
- 表现：刚插入
id=1001，下一条变成id=1033，中间空洞不可填 - 业务影响：只要不依赖“ID 连续”做分页、导出、审计比对，就可接受
- 别试图修复：没有配置项能关闭空洞，
innodb_autoinc_lock_mode也不提供“连续但低锁”的中间态 - 真正风险点：如果应用层把自增 ID 当作业务序号（比如订单号后缀），那 mode=2 就不该上
最易被忽略的是：改完 innodb_autoinc_lock_mode 后不查 binlog_format，或者误以为所有 INSERT 都受益于 mode=2——结果线上还是卡，却以为参数没生效。实际要先分清你压测/线上跑的到底是哪种 INSERT 类型。
