Lock wait timeout exceeded 并非真死锁，而是事务等锁超时被杀；真正死锁由InnoDB自动检测并回滚，且错误日志会明确记录两个事务的SQL和锁信息。
死锁日志里看到 Lock wait timeout exceeded 怎么快速定位
MySQL 死锁超时不是真死锁，而是事务等锁太久被主动杀掉；真正死锁会由 InnoDB 自动检测并回滚一个事务，同时在错误日志里写明两个事务的 SQL 和锁信息。所以第一步不是看应用报错，而是查 MySQL 的 error log：SHOW VARIABLES LIKE 'log_error';，然后 grep InnoDB 和 deadlock。
关键线索藏在那段堆栈里：谁在等 PRIMARY 上的 X 锁，谁又持有了 gap 锁或 next-key 锁。常见陷阱是以为“主键插入只锁记录”，其实二级索引缺失、INSERT ... SELECT 或唯一键冲突都会触发 gap 锁蔓延，让本不相关的插入互相卡住。
- 用
SHOW ENGINE INNODB STATUS\G看最近一次死锁详情（注意它只保留最后一次） - 如果业务用的是批量
INSERT，检查是否按主键升序排列——乱序插入极易触发 gap 锁交叉 - 确认表有没有非空唯一索引：有就意味每次插入都要先查唯一性，查的过程就加了 gap 锁
为什么自增主键 + INSERT IGNORE 也容易死锁
表面看 INSERT IGNORE 是“不报错就插，报错就跳过”，但底层仍要走完整唯一约束检查流程。如果多个并发线程同时尝试插入相同 UNIQUE 值（比如业务生成的业务单号），它们会在该值对应的索引间隙上争抢 insert intention 锁，而这个锁和 gap 锁互斥，就卡住了。
更隐蔽的问题是：即使主键是自增，只要语句里显式指定了主键值（比如 INSERT INTO t(id, name) VALUES (100, 'a')），InnoDB 就不会跳过 gap 锁检查，哪怕这个 id 根本没被用过。
- 避免在高并发写场景下依赖
INSERT IGNORE或REPLACE INTO做“存在则更新”逻辑 - 改用
SELECT ... FOR UPDATE+INSERT/UPDATE显式控制，但要注意 select 范围别太大，否则 gap 锁范围也大 - 如果必须用
INSERT ... ON DUPLICATE KEY UPDATE，确保ON DUPLICATE只针对主键或明确的唯一索引，不要模糊匹配
调整插入顺序真能减少死锁？怎么调才有效
能，但前提是“顺序”指的是按聚簇索引（通常是主键）物理顺序插入。InnoDB 插入新行时，会先定位到 B+ 树叶子页位置，再加锁；如果并发线程都往同一个页尾追加，锁竞争集中在一页；如果各自往不同页插，锁分散，冲突概率下降。
问题在于：很多业务生成的 ID（比如雪花算法、UUID）天然无序，或者前端传来的批量数据没排序就直接 INSERT。这时候即使主键是自增，插入顺序乱，InnoDB 仍得频繁分裂页、移动记录，引发更多锁等待。
- 后端接收批量插入请求后，务必对
id字段做升序排序再执行INSERT - 用
LOAD DATA INFILE导入时，提前用ORDER BY排好源数据，比导入后再建索引更省锁 - 不要迷信“主键自增就安全”——如果表有二级唯一索引，插入时仍需按该索引顺序加锁，此时二级索引顺序才是关键
innodb_autoinc_lock_mode 设成 2 真的安全吗
设成 2（interleaved mode）确实能提升并发插入性能，尤其大批量 INSERT ... SELECT 场景，但它会牺牲自增值的连续性，并且在 binlog statement 格式下可能造成主从不一致。更重要的是：它只影响 INSERT 类语句获取 auto-increment 值时的锁行为，不影响插入过程中对记录本身的行锁或 gap 锁。
换句话说，调这个参数治标不治本——死锁根源往往在索引结构、插入数据分布或事务粒度，而不是自增锁本身。
- 除非你明确在用
INSERT ... SELECT或REPLACE批量操作，否则没必要动innodb_autoinc_lock_mode - 设成 2 后，如果还出死锁，说明问题不在自增分配，而在其他锁资源争抢，该查索引、该调顺序还得做
- 线上改这个参数需重启实例或至少重连所有连接，风险不小，别为“听起来高级”去调
最常被忽略的一点：死锁往往不是单条 SQL 的问题，而是多个事务交叉持有不同资源。排查时盯着一条 insert 看没用，得还原整个事务链路——它前面有没有 SELECT ... FOR UPDATE？有没有没提交的 update？有没有跨表操作？这些细节比主键类型重要得多。
