MySQL死锁本质是事务间加锁顺序冲突或循环等待，即使单行操作、低并发也会发生；根本原因包括UPDATE顺序不一致、间隙锁干扰、索引缺失、ORM隐式SQL及长事务等；解决需统一加锁顺序、显式FOR UPDATE一次性锁定、缩短事务、确保索引命中并合理设置隔离级别。
死锁不是并发高导致的，而是两个事务对同一行加锁顺序冲突或锁等待循环——哪怕只有一行、两个事务，也会秒级触发。
UPDATE 同一行为什么会死锁？
很多人以为“UPDATE 同一行”只会排队，不会死锁。但实际中，只要事务里混入其他锁操作，就可能形成循环等待：
- 事务 A 先
SELECT * FROM t WHERE id = 1 FOR UPDATE（锁住 id=1），再执行UPDATE t SET x = 1 WHERE id = 2（试图锁 id=2） - 事务 B 反过来先锁 id=2，再尝试锁 id=1
- 结果：A 持有 id=1 等 id=2，B 持有 id=2 等 id=1 → InnoDB 或 SQL Server 立即检测并回滚其中一个，报错
Deadlock found when trying to get lock或Error 1205
注意：即使语句表面都是 UPDATE t SET x = ? WHERE id = 1，如果它们嵌套在不同逻辑路径（比如 JOIN 子查询、触发器、或事务中前置的其他锁操作）里，仍可能因锁获取时机错位而死锁。
为什么加了 ORDER BY 还是死锁？
ORDER BY 本身不保证加锁顺序，它只在**执行计划真正走索引排序时才生效**。否则优化器可能全表扫描 + filesort，导致锁行顺序完全随机：
- 错误写法：
UPDATE t SET status = 'done' WHERE type = 'job' ORDER BY id，但type字段没索引 →EXPLAIN显示type: ALL、Extra: Using filesort→ 锁所有匹配行，顺序不可控 - 正确验证：
EXPLAIN FORMAT=TRADITIONAL SELECT * FROM t WHERE type = 'job' ORDER BY id，必须看到key非空、Extra不含Using filesort - 复合索引要满足最左前缀：有
(type, id)索引才能让上面语句走索引；只有(id, type)则无效
怎么避免单行 UPDATE 引发死锁？
核心是消除“先读再写”的隐式两阶段锁，改用原子、确定性更强的操作：
- 用乐观锁替代显式锁：
UPDATE t SET version = version + 1, status = 'done' WHERE id = 1 AND version = 123，失败说明已被更新，应用层重试即可 - 状态流转类更新必须带前置条件：
UPDATE orders SET status = 'shipped' WHERE id = 123 AND status = 'confirmed'，避免覆盖中间态 - 彻底绕过锁竞争：高频幂等写入（如计数、日志）改用
INSERT ... ON DUPLICATE KEY UPDATE（MySQL）或MERGE（SQL Server），前提是目标字段有UNIQUE约束 - 绝对不要在事务里混非 DB 操作：HTTP 调用、文件写入、复杂计算等会拉长锁持有时间，把它们移出
BEGIN TRAN/START TRANSACTION块
容易被忽略的关键点
死锁往往藏在“看起来安全”的地方：
-
SELECT ... FOR UPDATE即使查不到记录，也会在 RR 隔离级别下加间隙锁——多个并发请求对同一个不存在的order_no加锁，再同时INSERT，立刻死锁 - SQL Server 中，
UPDATE ... FROM关联子查询若没走索引，子查询可能先锁大量行，外层再锁目标行，扩大冲突面 - MySQL 的
LIMIT在UPDATE中不提供分页语义，UPDATE ... LIMIT 1并发执行时可能重复更新同一行（尤其配合ORDER BY RAND()） - 应用层捕获死锁错误后，重试前必须
ROLLBACK并等待几十毫秒，否则立即重试大概率再次撞上相同死锁链
