UPDATE ... WHERE id = ?在高并发下会死锁，是因为REPEATABLE-READ级别下对不存在的id加间隙锁，多个事务竞争同一间隙时，若后续执行INSERT ON DUPLICATE KEY UPDATE，会因插入意向锁与间隙锁互斥而形成循环等待。
为什么UPDATE ... WHERE id = ?在高并发下也会死锁？
不是语句本身有问题，而是多个事务对同一行反复执行UPDATE时，在REPEATABLE-READ隔离级别下会触发间隙锁（Gap Lock）或Next-Key Lock，尤其当该行附近存在其他索引值时。比如表里有id为10、15、20的记录，事务A更新id = 12（不存在），InnoDB会在(10,15)区间加间隙锁；事务B同时更新id = 13，也试图在同一个间隙加锁——两者不冲突，但一旦其中一方紧接着插入新记录（如INSERT ... ON DUPLICATE KEY UPDATE），就会因插入意向锁与间隙锁互斥而卡住。
INSERT ... ON DUPLICATE KEY UPDATE为什么是死锁高发操作？
它本质是“先查再插/更”，且在唯一索引上会同时申请两种锁：主键上的插入意向锁 + 唯一索引上的间隙锁。问题出在并发插入相邻值时：
- 事务T1插入
uid = 11，在uid索引的(10,15)区间加间隙锁，并持插入意向锁 - 事务T2插入
uid = 12，同样获取(10,15)间隙锁（间隙锁之间兼容），也申请插入意向锁 - T1回滚后，T2和T3都释放了部分锁，但彼此等待对方释放间隙锁 → 死锁
- 这种行为在MySQL 5.7中默认开启，5.6则不加该间隙锁
怎么快速确认是不是间隙锁惹的祸？
别只看SHOW ENGINE INNODB STATUS\G里的SQL，重点盯住WAITING FOR THIS LOCK TO BE GRANTED和HOLDS THE LOCK(S)两段：
- 如果看到
lock_mode X locks gap before rec或next-key lock，基本锁定是间隙锁冲突 - 检查
lock_trx_id是否指向一个早已COMMIT或ROLLBACK的事务——这说明锁没及时清理，常因连接池未正确归还连接导致 -
INNODB_LOCK_WAITS在5.7中不可靠，不要依赖它查阻塞链，直接用INNODB_TRX找trx_state = 'LOCK WAIT'并按trx_started排序
哪些改动能立刻降低死锁频率？
线上不能停机改表结构，优先做这几件事：
- 把事务隔离级别从
REPEATABLE-READ临时改为READ-COMMITTED：SET SESSION transaction_isolation = 'READ-COMMITTED';——它禁用间隙锁，但需确认业务能接受幻读 - 避免在事务中混用
SELECT ... FOR UPDATE和INSERT ... ON DUPLICATE KEY UPDATE，尤其是针对同一唯一键 - 批量更新时强制按主键升序排列ID：
UPDATE t SET x=1 WHERE id IN (13,11,12)→ 改成WHERE id IN (11,12,13)，让所有事务加锁顺序一致 - 检查是否有长事务在sleep或等RPC——这类事务不显眼，但持有的锁是死锁放大器
真正难的不是加锁逻辑，而是多个模块对同一张表的更新路径不统一。比如订单服务按order_id更新，库存服务却按sku_id更新，又没约定好加锁顺序，死锁就藏在协作缝隙里。
