为什么 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 锁。 尽量只保留一个业务主唯一键，其余用普通索引替代（如
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时间和应用日志回溯完整事务链路。
