死锁检测以及相应开销
由于事务之间可能产生死锁，因此要么设置最大等待超时时间，要么设置死锁检测。
死锁检测
1. 维护等待图（Wait-for Graph）
InnoDB 内部维护一个有向图，图中的节点表示事务（Transaction），边表示锁的等待关系。
例如：事务A持有行X的锁，事务B请求行X的锁并被阻塞，则图中有一条边从B指向A（B→A，表示B在等待A释放锁）。
当某个事务请求锁时，如果锁已被其他事务持有，InnoDB 会更新等待图，添加一条新的边。
2. 检测环（Cycle）
每次有事务请求锁失败（进入等待状态）时，InnoDB 会触发死锁检测。
深度优先搜索（DFS）：InnoDB 通过DFS遍历等待图，检查是否存在环。如果发现环，则判定为死锁。
优化：为了减少性能开销，InnoDB 不会每次都全图遍历，而是从新加入的边出发，仅检查可能形成环的路径。
3. 选择牺牲者（Victim）
如果检测到死锁，InnoDB 会选择一个事务作为牺牲者（通常选择回滚成本更低的事务，例如修改数据量较小的事务），强制回滚该事务，并释放其持有的锁。
回滚后，等待图中对应的边被移除，其他被阻塞的事务可以继续执行。
死锁的开销
问题
因此由于事务的不断加入，图会变得越来越大，进行环检测是O(n)的操作，若n很大则cpu大量消耗。
解决
可以通过中间件对操作相同key的事务限流，这样事务虽然也在等待，但是没有增加死锁检测的负担。
