InnoDB选择回滚“undo log量最小”的事务，依据是等待图算法检测到环形依赖后，按已修改行数等轻量级指标评估回滚代价，而非时间、SQL复杂度或客户端信息。
MySQL死锁后只有一个事务回滚，是因为InnoDB必须打破循环等待链——它不能同时回滚全部事务，否则所有操作都丢失，业务逻辑无法推进；它也不能不回滚任何事务，否则死锁永久存在。所以InnoDB选择“最小代价”那个事务回滚，让其余事务继续执行。
死锁检测触发回滚的判定依据是什么？
InnoDB用等待图（wait-for graph）实时追踪事务间的锁依赖关系。一旦发现环形依赖（比如事务A→等待事务B持有的锁，事务B→等待事务A持有的锁），就确认死锁成立。此时引擎会评估每个参与事务的“undo log 量”，即已做的修改行数、插入/更新/删除的数据量。undo_log越小的事务，回滚开销越低，就被选为牺牲者。
这个判断不是按事务开始时间、SQL复杂度或客户端IP，而是纯基于存储引擎内部的轻量级估算。你无法通过SQL控制谁被回滚，但可以通过减少单个事务的DML数量来降低被选中的概率。
为什么不是所有事务都回滚或都不回滚？
都不回滚 → 系统卡死，后续所有请求在该资源上持续等待，直到超时（innodb_lock_wait_timeout默认50秒），这不是死锁处理，是锁等待超时，影响面更大。
都回滚 → 违反ACID中的“持久性”和“原子性”预期：应用层通常假设“至少有一个能成功”，比如两个支付扣款事务冲突，全回滚意味着两笔钱都没扣，业务需额外补偿逻辑，反而更难兜底。
只回滚一个 → 是工程上的折中：用最小扰动恢复系统活性。这也是为什么应用代码必须捕获错误码 1213（Deadlock found when trying to get lock; try restarting transaction），而不是忽略或当普通异常处理。
回滚一个事务就能彻底解决问题吗？
能解除当前死锁，但不等于根除风险。常见疏漏包括：
- 重试逻辑没做幂等控制，导致重复扣款或重复下单
- 事务里混用了不同索引路径（例如一个走
id主键更新，另一个走name非唯一索引+间隙锁），下次并发仍可能在相同资源上再次形成环 - 把
innodb_deadlock_detect=OFF当成优化手段，结果死锁不再自动处理，全部退化为锁等待超时，响应毛刺更明显
真正稳定的解法，是让所有写路径对同一组资源保持**固定加锁顺序**，比如统一按user_id升序 → order_id升序更新，从源头消除循环等待的可能性。
