根本原因是事务持锁时间过长且加锁顺序不一致，导致间隙锁/临键锁引发环形等待；需优化索引、统一加锁顺序、避免事务中耗时操作，并开启innodb_print_all_deadlocks监控。
为什么 UPDATE 语句在高并发下会卡住甚至报死锁？
根本原因不是“并发太高”，而是事务持有锁的时间过长 + 加锁顺序不一致。MySQL 的 InnoDB 默认用行锁，但若查询条件没走索引、或用了范围条件（如 WHERE status IN (1,2)），就可能升级为间隙锁（Gap Lock）或临键锁（Next-Key Lock），锁住一段索引区间——多个事务交叉更新不同行却覆盖同一间隙时，极易形成环形等待。
典型现象：Deadlock found when trying to get lock; try restarting transaction 错误频繁出现，且 SHOW ENGINE INNODB STATUS\G 显示两个事务各自持有一把锁、又在等对方另一把锁。
- 检查是否缺失索引：对
WHERE和ORDER BY字段建联合索引，避免全表扫描触发表级锁升级 - 确保更新语句能命中唯一索引：优先用
WHERE id = ?而非WHERE name = ?（除非name是唯一索引） - 避免在事务中做 HTTP 调用、文件读写等外部耗时操作——锁会一直持有着
如何让 SELECT ... FOR UPDATE 不成为死锁源头？
SELECT ... FOR UPDATE 本身不直接导致死锁，但它会让事务提前加锁，如果后续 UPDATE 顺序和别的事务不一致，就埋下死锁隐患。更危险的是：它默认在可重复读（REPEATABLE-READ）隔离级别下会加临键锁，锁住查到的记录及其前后间隙。
实操建议：
- 只在真正需要“读取后立即修改”的场景才用
FOR UPDATE；纯校验逻辑优先用SELECT ... LOCK IN SHARE MODE或干脆不加锁 + 应用层重试 - 所有涉及该表的
FOR UPDATE查询，强制按主键ORDER BY id ASC排序，保证加锁顺序全局一致 - 若业务允许，临时降级隔离级别为
READ-COMMITTED：此时FOR UPDATE只锁匹配行，不锁间隙，死锁概率大幅下降（但需确认是否影响一致性）
INSERT ... ON DUPLICATE KEY UPDATE 真的线程安全吗？
它在绝大多数场景下是原子的，但“线程安全”不等于“无锁竞争”。当存在多个唯一索引（比如 UNIQUE(email) 和 UNIQUE(phone)）时，InnoDB 可能因内部加锁顺序不同而引发死锁——尤其在并发插入冲突值时。
常见错误现象：两个事务同时执行 INSERT ... ON DUPLICATE KEY UPDATE，一个插 email='a@b' 冲突于 email 索引，另一个插 phone='123' 冲突于 phone 索引，两者分别持有一个唯一索引的 S 锁，又互相申请对方持有的 X 锁。
- 尽量只保留一个业务主唯一键，其余用普通索引替代（如
email做主唯一键，phone改为普通索引+应用层查重） - 冲突更新字段尽量少：避免
ON DUPLICATE KEY UPDATE updated_at=NOW(), version=version+1, extra_json=JSON_SET(...)这类复杂更新，减少锁持有时间 - 捕获死锁异常后，必须重试整个事务（不只是这条 SQL），否则状态可能不一致
监控与定位死锁的最小可行方案
别等用户报错才查。InnoDB 每次死锁都会记录到 INFORMATION_SCHEMA.INNODB_TRX 和 INFORMATION_SCHEMA.INNODB_LOCK_WAITS，但更直接的是开启死锁日志。
执行以下命令打开实时记录（无需重启）：
SET GLOBAL innodb_print_all_deadlocks = ON;
日志默认输出到 MySQL 错误日志（mysqld.err），每条记录包含：两个事务的 SQL、持有锁、等待锁、索引信息。重点关注 “HELD THE LOCK(S)” 和 “WAITING FOR THIS LOCK TO BE GRANTED” 两段。
容易被忽略的一点：死锁日志里显示的 SQL 往往是事务中较晚执行的语句，但真正问题可能出在前面的 SELECT ... FOR UPDATE 或未提交的 UPDATE —— 所以要结合 trx_started 时间和应用日志回溯完整事务链路。
