构造数据库死锁的核心在于故意制造资源竞争，通过让两个或多个事务以相反顺序锁定相同资源，导致它们无限期互相等待，通常用于测试数据库的并发控制机制和死锁检测能力。
死锁并非数据库的故障,而是并发控制下的必然现象，理解并模拟死锁，是DBA（数据库管理员）和后端开发人员的必修课，它像是一场精心设计的“交通堵塞”，只有看清了拥堵的原理，才能疏通道路。
死锁形成的四大必要条件
要构造死锁,首先得明白死锁是怎么发生的，业内专家指出，死锁的产生必须同时满足四个条件，缺一不可，这四个条件就像四把锁，只有全部打开，死锁才会出现。
互斥条件
资源在一段时间内只能被一个事务使用,当你正在修改一行数据时，其他事务必须等待你完成，不能同时修改同一行，这是数据库保证数据一致性的基础。
占有并等待
一个事务已经持有了至少一个资源,但又提出了新的资源请求，而该资源已被其他事务占有，请求事务阻塞自己，但又不释放已持有的资源，这就好比一个人占着两个座位，还要求别人把第三个座位让给他，自己却赖着不走。
不可抢占
事务持有的资源,在未使用完之前，不能被其他事务强行夺走，数据库不会主动踢掉一个正在执行的事务来释放资源，除非发生超时或检测到死锁。
循环等待
这是构造死锁最关键的一环,事务A等待事务B释放资源，事务B等待事务A释放资源，形成一个闭环，如果没有这个闭环，死锁就不会发生。
如何构造数据库死锁：实操场景解析
知道了原理,接下来就是动手，构造死锁通常发生在多线程或高并发场景下，我们将通过具体的SQL操作来演示这一过程。
反向加锁顺序
这是最经典的死锁构造方法,假设有两张表：User 和 Order。
- 事务A 首先锁定
User表中的某一行，然后尝试锁定Order表中的某一行。 - 事务B 首先锁定
Order表中的某一行，然后尝试锁定User表中的某一行。
当这两个事务几乎同时执行时：
- 事务A锁住了
User行，等待Order行。 - 事务B锁住了
Order行，等待User行。 - 双方都在等待对方释放锁,于是死锁形成。
在MySQL中,你可以开启两个数据库连接窗口，分别执行以下操作来复现这一场景：
- 窗口1：开启事务，执行
UPDATE User SET name='test' WHERE id=1; - 窗口2：开启事务，执行
UPDATE Order SET status='paid' WHERE user_id=1; - 窗口1：继续执行
UPDATE Order SET status='pending' WHERE user_id=1; - 窗口2：继续执行
UPDATE User SET name='test2' WHERE id=1;
窗口1和窗口2都会挂起,直到其中一个事务超时或被数据库引擎检测为死锁 victim 并回滚。
间隙锁与Next-Key Locks
在InnoDB引擎中,除了行锁，还有间隙锁，构造此类死锁需要更精细的操作。
- 事务A在一个范围内插入数据,持有间隙锁。
- 事务B尝试在该范围内插入相同的数据,被阻塞。
- 事务C尝试修改被事务A锁定的行,也被阻塞。
- 如果事务B和事务C之间存在资源依赖,也可能形成死锁。
这种死锁在SELECT ... FOR UPDATE或INSERT操作中较为常见，特别是在高并发插入场景下。
数据库死锁检测与处理机制
数据库并不是对死锁束手无策,现代关系型数据库都内置了死锁检测机制，旨在最小化对业务的影响。
死锁检测算法
数据库维护一个等待图（Wait-for Graph），当事务请求锁时，如果资源被占用，它会被加入等待图，数据库定期运行检测算法，查找图中是否存在环，如果存在环，说明发生了死锁。
- 检测频率：多数情况下，数据库每隔几秒运行一次检测。
- 选择受害者：一旦检测到死锁，数据库会选择一个事务作为“受害者”进行回滚，以打破循环，选择标准通常基于回滚成本，比如回滚事务A的成本低于事务B，则选择A。
死锁日志分析
当死锁发生时,数据库会记录详细的死锁日志，对于MySQL InnoDB，可以通过 SHOW ENGINE INNODB STATUS 查看最近的死锁信息。
日志中会包含：
- 涉及的事务ID。
- 每个事务持有的锁和等待的锁。
- 涉及的SQL语句。
- 被选为受害者的事务。
分析这些日志是优化数据库性能的关键步骤,通过日志，你可以发现代码中潜在的锁竞争问题。
预防数据库死锁的最佳实践
构造死锁是为了理解它,但生产环境中，我们需要避免它，以下是一些经过验证的预防策略。
保持一致的加锁顺序
这是最简单也最有效的预防措施,所有事务都以相同的顺序访问资源，如果事务A先锁User再锁Order，那么事务B也必须先锁User再锁Order，这样就不会形成循环等待。
缩短事务持有锁的时间
事务越短,锁持有的时间就越短，发生冲突的概率就越低。
- 避免在事务中进行复杂的计算或外部API调用。
- 将非必要的操作移出事务范围。
- 使用乐观锁代替悲观锁,减少锁的持有时间。
使用合适的隔离级别
较高的隔离级别（如Serializable）会导致更多的锁竞争，而较低的隔离级别（如Read Committed）则可能减少锁冲突，但可能带来脏读等问题，根据业务需求选择合适的隔离级别，可以在性能和一致性之间取得平衡。
避免大事务
大事务不仅持有锁的时间长,还可能导致锁表升级，影响其他事务，尽量将大事务拆分为多个小事务，或者分批处理。
常见疑问解答
数据库死锁检测机制是如何工作的？
数据库通过构建等待图来检测死锁,每个事务是一个节点，锁请求是边，如果图中存在环，则说明发生了死锁，数据库会选择一个事务回滚以打破环。
如何避免MySQL中的死锁？
保持加锁顺序一致、缩短事务时间、使用合适的索引避免全表扫描导致的间隙锁竞争，以及合理设置隔离级别，是避免MySQL死锁的主要手段。
死锁和锁超时有什么区别？
死锁是多个事务互相等待,形成循环，无法自动解除，需要数据库介入检测并回滚其中一个事务，锁超时是单个事务等待锁的时间超过了设定的阈值，数据库会自动回滚该事务，死锁是逻辑上的互相等待，锁超时是时间上的限制。
首发原创文章，作者：世雄 - 原生数据库架构专家，如若转载，请注明出处：https://idctop.com/article/205587.html
