内容简介：Innodb锁介绍-Innodb中死锁
死锁
当两个以上的运算单元，双方都在等待对方停止运行，以获取系统资源，但是没有一方提前退出时，就称之为死锁。
死锁问题是计算机系统中常见的问题，在Innodb中同样存在。
死锁的产生条件
死锁产生必须要满足以下四个条件：
- 互斥条件 : 即为某个资源在同一时间只允许被一个单元占有。
- 不可抢占条件 :被单元占有的资源不可被其它单元抢占。
- 占有且申请条件 :单元当前至少占有一个资源，且该单元同时向系统申请其它的资源。
- 循环等待条件 :单元之前存在一个资源的循环等待序列。
死锁范例
在百度上盗了一张图，如图所示，单元T1和T2各自占有了一个资源，又同时想要占据别人的资源，这样僵持不下，也就产生了死锁。对于计算机系统而言，死锁会导致系统停滞，对于Innodb而言，死锁会给数据的读写产生阻碍。
Innodb中的死锁
在介绍之前，先讲一个我们工作中踩到的一个坑。
背景描述
我们的订单表中存在一个Unique Key，假设该Unique Key的名字为U_KEY，它是由一个ID和时间戳构成的。在实际运行中，存在用同一个Unique Key反复创建订单的行为，这种情况的发生有可能是因为恶意刷单或者是偶然的请求重发。对于这种情况，最先到达的插入请求会成功，之后的请求会产生Unique Key冲突而失败，但这个过程中会时不时的出现Dead Lock Detected的情况(数据库会自己去Kill死锁的)，这里我们采用的是 insert ignore
。
在插入时，MySQL会给行记录加上排他锁(index-record lock)，假如此时有三个同样的插入请求，都开启了事务，其中一个先拿到了排他锁开始插入，之后的事务会出现Duplicate Key错误，而此时它们会申请该行的共享锁，如果这个时候拿到排他锁的事务回滚，那么另外两个事务会同时申请该行的排他锁（过程参考 MySQL锁机制 。由于排他锁和共享锁是互斥的，此时就产生了死锁的情况。
这里可能会有人有疑问，为什么出现Duplicate Key错误的时候会加共享锁了，我的理解是冲突检测本身是一种读操作，所以冲突之后的轮询需要加共享锁。
以上就是本文的全部内容，希望对大家的学习有所帮助，也希望大家多多支持 码农网
本站部分资源来源于网络，本站转载出于传递更多信息之目的，版权归原作者或者来源机构所有，如转载稿涉及版权问题，请联系我们。
