做家：小林coding
纲目以下：正文有个生意要紧逻辑即是新增定单、批改定单、查问定单等操纵。而后由于定单是不能反复的，因而那时在新增定单的时辰做了幂等性校验，做法即是在新增定单纪录以前，先经过select...forupdate语句查问定单是不是存在，假使不存在才插入定单纪录。
而恰是由于如许的操纵，当生意量很大的时辰，就或许会涌现死锁。
接下来跟众人聊下为甚么会产存亡锁，以及何如避让死锁。
死锁的产生本次案例利用储备引擎Innodb，断绝级别为可反复读（RR）。
接下来，我用实战的方法来带众人看看死锁是何如产生的。
我建了一张定单表，个中id字段为主键索引，order_no字段通俗索引，也就长短独一索引：
CREATETABLE`t_order`(`id`intNOTNULLAUTO_INCREMENT,`order_no`intDEFAULTNULL,`create_date`datetimeDEFAULTNULL,PRIMARYKEY(`id`),KEY`index_order`(`order_no`)USINGBTREE)ENGINE=InnoDB;
而后，先t_order内外目前曾经有了6笔纪录：
图片假定这时有两事宜，一个事宜要插入定单，此外一个事宜要插入定单，由于需求对定单做幂等性校验，因而两个事宜先要查问该定单是不是存在，不存在才插入纪录，进程以下：
图片能够看到，两个事宜都堕入了等候形态（前提没有翻开死锁探测），也即是产生了死锁，由于都在互相等候对方释放锁。
这边在查问纪录是不是存在的时辰，利用了select...forupdate语句，宗旨为了避让事宜施行的进程中，有其余事宜插入了纪录，而涌现幻读的题目。
假使没有利用select...forupdate语句，而利用了天真的select语句，假使是两个定单号同样的乞求同时进入，就会涌现两个反复的定单，有或许涌现幻读，以下图：
为甚么会形成死锁？可反复读断绝级别下，是存在幻读的题目。
Innodb引擎为明白决「可反复读」断绝级别下的幻读题目，就引出了next-key锁，它是纪录锁和空隙锁的组合。
RecordLoc，纪录锁，锁的是纪录自己；GapLock，空隙锁，锁的即是两个值之间的清闲，以避让其余事宜在这个清闲间插入新的数据，进而避让幻读景象。通俗的select语句是不会对纪录加锁的，由于它是经过MVCC的机制完成的快照读，假使要在查问时对纪录加行锁，能够利用底下这两个方法：
begin;//对读取的纪录加同享锁select...lockinsharemode;