[[442673]]

本文转载自微信公众号「小林coding」，作家小林coding。转载本文请干系小林coding公众号。

巨匠好，我是小林。

说个很早之前我方遭受过数据库死锁问题。

有个业务主要逻辑即是新增订单、修改订单、查询订单等操作。然后因为订单是不成调换的，是以那时在新增订单的时候作念了幂等性校验，作念法即是在新增订单记载之前，先通过 select ... for update 语句查询订单是否存在，要是不存在才插入订单记载。

而恰是因为这么的操作，当业务量很大的时候，就可能会出现死锁。

接下来跟巨匠聊下为什么会发死活锁，以及怎么幸免死锁。

死锁的发生

本次案例使用存储引擎 Innodb，阻遏级别不可调换读(RR)。

接下来，我用实战的形势来带巨匠望望死锁是怎么发生的。

我建了一张订单表，其中 id 字段为主键索引，order_no 字段等闲索引，也就曲直唯独索引：

CREATE kaiyun体育TABLE `t_order` (   `id` int NOT NULL AUTO_INCREMENT,   `order_no` int DEFAULT NULL,   `create_date` datetime DEFAULT NULL,   PRIMARY KEY (`id`),   KEY `index_order` (`order_no`) USING BTREE ) ENGINE=InnoDB ; 

然后，先 t_order 内外当今依然有了 6 札记载：

假定这时有两事务，一个事务要插入订单 1007 ，另外一个事务要插入订单 1008，因为需要对订单作念幂等性校验，是以两个事务先要查询该订单是否存在，不存在才插入记载，历程如下：

不错看到，两个事务齐堕入了恭候情景(前提莫得翻开死锁检测)，也即是发生了死锁，因为齐在互特出待对方开释锁。

这里在查询记载是否存在的时候，使用了 select ... for update 语句，揣测打算为了驻防事求实行的历程中，有其他事务插入了记载，而出现幻读的问题。

要是莫得使用 select ... for update 语句，而使用了单纯的 select 语句，要是是两个订单号相同的申请同期进来，就会出现两个调换的订单，有可能出现幻读，如下图：

为什么会产死活锁?

可调换读阻遏级别下，是存在幻读的问题。

Innodb 引擎为了处治「可调换读」阻遏级别下的幻读问题，就引出了 next-key 锁，它是记载锁和过错锁的组合。

Record Loc，记载锁，锁的是记载自己; Gap Lock，过错锁，锁的即是两个值之间的闲隙，以驻防其他事务在这个闲隙间插入新的数据，从而幸免幻读自得。

等闲的 select 语句是不会对记载加锁的，因为它是通过 MVCC 的机制达成的快照读，要是要在查询时对记载加行锁，不错使用底下这两个形势：

begin; //对读取的记载加分享锁 select ... lock in share mode; commit; //锁开释  begin; //对读取的记载加排他锁 select ... for update; commit; //锁开释 

行锁的开释时机是在事务提交(commit)后，锁就会被开释，并不是一条语句实行完就开释行锁。

比如，底下事务 A 查询语句会锁住(2, +∞]限度的记载，然后技巧要是有其他事务在这个锁住的限度插入数据就会被窒碍。

next-key 锁的加锁法律评释其实挺复杂的，在一些场景下会退化成记载锁或过错锁，我之前也写一篇加锁法律评释，凝视不错看这篇「我作念了一天的实际!」

需要看重的是，next-key lock 锁的是索引，而不是数据自己，是以要是 update 语句的 where 要求没灵验到索引列，那么就会全表扫描，在别称次扫描的历程中，不仅给行加上了行锁，还给行双方的闲隙也加上了过错锁，相配于锁住总共表，然后直到事务限定才会开释锁。

是以在线上千万不要实行莫得带索引要求的 update 语句，否则会形成业务停滞，我有个读者就因为干了这个事情，然后被雇主教授了一波，凝视不错看这篇「完蛋，公司被一条 update 语句干趴了!」

回到前边死锁的例子，在实行底下这条语句的时候：

select id from t_order where order_no = 1008 for update; 

因为 order_no 不是唯独索引，是以行锁的类型是过错锁，于是过错锁的限度是(1006, +∞)。那么，当事务 B 往过错锁里插入 id = 1008 的记载就会被锁住。

因为当咱们实行以下插入语句时，会在插入过错上再次赢得插入意向锁。

insert into t_order (order_no, create_date) values (1008, now()); 

插入意向锁与过错锁是冲突的，是以当其它事务捏有该过错的过错锁时，需要恭候其它事务开释过错锁之后，智商赢得到插入意向锁。而过错锁与过错锁之间是兼容的，是以是以两个事务中 select ... for update 语句并不会互相影响。

案例中的事务 A 和事务 B 在实行完后 select ... for update 语句后齐捏有限度为(1006,+∞)的过错锁，而接下来的插入操四肢了赢得到插入意向锁，齐在恭候对方事务的过错锁开释，于是就形成了轮回恭候，导致死锁。

怎么幸免死锁?

死锁的四个必要要求：互斥、占有且恭候、不可强占用、轮回恭候。惟有系统发死活锁，这些要求势必开拓，然则惟有粗疏随心一个要求就死锁就不会开拓。

在数据库层面，有两种计谋通过「龙套轮回恭候要求」来撤废死锁情景：

建立事务恭候锁的超每每候。当一个事务的恭候时候升迁该值后，就对这个事务进行回滚，于是锁就开释了，另一个事务就不错不息实行了。在 InnoDB 中，参数 innodb_lock_wait_timeout 是用来建立超每每候的，默许值时 50 秒。

当发生超时后，就出现底下这个辅导：

开启主动死锁检测。主动死锁检测在发现死锁后，主动回滚死锁链条中的某一个事务，让其他事务得以不息实行。将参数 innodb_deadlock_detect 建立为 on，默示开启这个逻辑，默许就开启。

当检测到死锁后，就会出现底下这个辅导：

上头这个两种计谋是「当有死锁发生时」的幸免形势。 

咱们不错总结业务的角度来退缩死锁，对订单作念幂等性校验的揣测打算是为了保证不会出现调换的订单，那咱们不错径直将 order_no 字段建立为唯独索引列，专揽它的唯独下来保证订单表不会出现调换的订单，不外有小数不好的场所即是在咱们插入一个依然存在的订单记载时就会抛出极度。