转账死锁本质是事务加锁顺序不一致引发循环等待，必须强制所有事务按主键升序（MIN/ MAX id）锁定账户，确保先锁小ID再锁大ID，并避免非索引查询、长事务及跨实体操作。
转账操作死锁不是代码写错了，而是事务加锁顺序不一致导致的循环等待——只要两个事务更新同一组账户但顺序相反，就极大概率触发 Deadlock found when trying to get lock; try restarting transaction。
为什么转账容易死锁
本质是“先锁 A 再锁 B”和“先锁 B 再锁 A”同时发生。比如：
- 事务 A：UPDATE account SET balance = balance - 100 WHERE id = 1; → UPDATE account SET balance = balance + 100 WHERE id = 2;
- 事务 B：UPDATE account SET balance = balance - 50 WHERE id = 2; → UPDATE account SET balance = balance + 50 WHERE id = 1;
InnoDB 按语句执行顺序加锁，A 持有 id=1 等 id=2，B 持有 id=2 等 id=1，立刻形成循环等待。
必须按主键升序加锁
所有转账逻辑统一按 id 升序锁定账户，就能彻底打破循环等待。不是靠运气，是强制约定。
- 计算出两个账户 ID，取小值在前、大值在后：
MIN(from_id, to_id)和MAX(from_id, to_id) - SQL 必须写成：UPDATE ... WHERE id = ?（小ID）; UPDATE ... WHERE id = ?（大ID）
- 哪怕业务上是“B 给 A 转”，代码里也先更新 A（id 小），再更新 B（id 大）
- 如果用
SELECT ... FOR UPDATE，务必加ORDER BY id，否则优化器可能打乱顺序
避免隐式锁升级和长事务
死锁常被放大，是因为锁范围变大或持有时间变长。
-
WHERE条件必须走索引：id 是主键，没问题；但若用WHERE user_id = 'xxx'，而user_id没索引，会锁全表，死锁面指数级上升 - 事务内禁止调外部接口、文件 IO、sleep：一次转账应在毫秒级完成，超过 100ms 就该警惕
- 不要在一个事务里做“查余额→判断→扣款→写日志→发消息”，只保留最核心的两条 UPDATE
- 批量转账？拆成单笔事务，别用一个事务锁 100 行——
innodb_lock_wait_timeout默认 50 秒，但应用层应设 3–5 秒超时并自动重试
上线前必须验证锁顺序
光看代码没用，得用 SHOW ENGINE INNODB STATUS 看真实加锁行为。
- 在测试环境模拟双事务交叉转账，立即执行该命令
- 重点看
LATEST DETECTED DEADLOCK下的两段TRANSACTION中的mysql tables in use和LOCK WAIT行 - 确认两个事务是否真的按相同顺序访问了同一组
id—— 如果出现id=5等id=3，说明排序逻辑漏了或没生效 - 别依赖开发环境日志，生产库的锁行为受并发、数据分布、统计信息影响，必须压测验证
真正难的不是写对第一笔转账，而是确保所有服务、所有语言、所有 SDK 在所有分支路径下，都遵守同一套锁序规则——漏一处，就可能在线上某个凌晨三点爆发死锁。
