MySQL 自增锁（AUTO_INCREMENT Lock）到底锁什么
MySQL 的
AUTO_INCREMENT列在插入时并非“无锁”，而是由一个表级的轻量级互斥机制保护——但这个机制在不同存储引擎和版本中行为差异极大。InnoDB 在 5.1.22+ 默认使用
innodb_autoinc_lock_mode=1（连续模式），此时普通
INSERT不锁表，只对语句执行期间预分配的自增值加内存计数；但
INSERT ... SELECT、
REPLACE ... SELECT或带子查询的批量插入仍会持有
TABLE LOCK直到语句结束。
容易踩的坑：
innodb_autoinc_lock_mode=0（传统模式）下，所有带
AUTO_INCREMENT的
INSERT都会持表锁，高并发插入直接串行化 即使
lock_mode=1，若事务中混用
INSERT ... SELECT和单行
INSERT，自增 ID 可能不连续且间隙变大 主从复制时，
STATEMENT格式依赖自增值顺序，
lock_mode=2（交错模式）可能导致从库复制失败
为什么 INSERT ... SELECT 容易触发长等待甚至死锁
这类语句本质是先读（SELECT 部分）再写（INSERT 部分），InnoDB 会对 SELECT 扫描的每一行加
next-key lock，同时为新插入行申请自增 ID —— 如果多个事务并发执行相似语句，可能形成「A 等 B 的写锁，B 等 A 的读锁」的循环依赖。
典型现象：
SHOW ENGINE INNODB STATUS中看到
*** (1) WAITING FOR THIS LOCK TO BE GRANTED: ... AUTO_INC和
*** (2) HOLDS THE LOCK(S): ... index `PRIMARY` of table `db`.`t` trx id ...并列出现。
实操建议：
避免在高并发写场景下用INSERT INTO t1 SELECT ... FROM t2，改用应用层分页 + 批量单行
INSERT确需批量导入时，临时设
SET innodb_autoinc_lock_mode = 2（仅限
ROW复制格式），但要接受 ID 不连续 给
SELECT部分显式加
SELECT ... FOR UPDATE或
LOCK IN SHARE MODE，让锁范围明确，减少隐式锁升级
REPLACE、INSERT ON DUPLICATE KEY UPDATE 与自增锁的交互
REPLACE实际是
DELETE + INSERT，会触发两次自增逻辑：DELETE 不影响计数器，但 INSERT 必然消耗一个新 ID，即使最终因唯一键冲突被回滚，ID 也不会回收 —— 这导致 ID 快速耗尽，且在并发下加剧锁竞争。
INSERT ... ON DUPLICATE KEY UPDATE更安全：它先尝试插入，冲突时转为更新，**不额外申请自增 ID**（除非真正插入了新行）。但注意：如果表有多个唯一索引，冲突检测顺序依赖索引定义顺序，可能意外触发插入而非更新。
关键区别：
REPLACE总是增加
auto_increment值，哪怕没真正插入
INSERT ... ON DUPLICATE KEY UPDATE仅在实际插入新行时才推进计数器 两者在冲突路径上都可能持有
gap lock，但
REPLACE的 DELETE 阶段还会持有被删行的记录锁，延长锁持有时间
如何验证当前自增锁行为是否异常
不能只看
SHOW CREATE TABLE，必须结合运行时状态判断。最直接的方式是观察
information_schema.INNODB_TRX和
INNODB_LOCK_WAITS，并比对
innodb_autoinc_lock_mode设置。
快速检查命令：
SELECT VARIABLE_VALUE FROM performance_schema.global_variables WHERE VARIABLE_NAME = 'innodb_autoinc_lock_mode';
模拟竞争验证：
-- 会话 A START TRANSACTION; INSERT INTO t VALUES (); -- 占住一个自增 ID -- 不提交
-- 会话 B（立即执行） INSERT INTO t SELECT * FROM t LIMIT 1; -- 观察是否卡住
真正复杂的地方在于：自增锁本身不记录在
INNODB_LOCKS表中，它是内存态的轻量结构，只能通过等待现象、错误日志（如
Lock wait timeout exceeded）和
SHOW ENGINE INNODB STATUS中的
AUTO_INC提示交叉印证。线上环境一旦出现自增相关延迟，优先查
lock_mode配置和是否有隐式批量插入语句。
