MySQL死锁分析与解决之路

来自：贝壳DBA

咱们使用 MySQL 大概率上都会遇到死锁问题，这实在是个令人非常头痛的问题。本文将会对死锁进行相应介绍，对常见的死锁案例进行相关分析与探讨，以及如何去尽可能避免死锁给出一些建议。

--什么是死锁 --

死锁是并发系统中常见的问题，同样也会出现在数据库MySQL的并发读写请求场景中。当两个及以上的事务，双方都在等待对方释放已经持有的锁或因为加锁顺序不一致造成循环等待锁资源，就会出现“死锁”。常见的报错信息为 ” Deadlock found when trying to get lock... ”。

举例来说 A 事务持有 X1 锁 ，申请 X2 锁，B事务持有 X2 锁，申请 X1 锁。A 和 B 事务持有锁并且申请对方持有的锁进入循环等待，就造成了死锁。

如上图，是右侧的四辆汽车资源请求产生了回路现象，即死循环，导致了死锁。

从死锁的定义来看，MySQL 出现死锁的几个要素为：

a.两个或者两个以上事务

b.每个事务都已经持有锁并且申请新的锁

c.锁资源同时只能被同一个事务持有或者不兼容

d.事务之间因为持有锁和申请锁导致彼此循环等待

说明：后续内容实验环境为 5.7 版本，隔离级别为 RR（可重复读）

-- InnoDB 锁类型--

为了分析死锁，我们有必要对 InnoDB 的锁类型有一个了解。

MySQL InnoDB 引擎实现了标准的行级别锁：共享锁( S lock ) 和排他锁 ( X lock )

• 不同事务可以同时对同一行记录加 S 锁。
• 如果一个事务对某一行记录加 X 锁，其他事务就不能加 S 锁或者 X 锁，从而导致锁等待。

如果事务 T1 持有行 r 的 S 锁，那么另一个事务 T2 请求 r 的锁时，会做如下处理：

• T2 请求 S 锁立即被允许，结果 T1 T2 都持有 r 行的 S 锁
• T2 请求 X 锁不能被立即允许

如果 T1 持有 r 的 X 锁，那么 T2 请求 r 的 X、S 锁都不能被立即允许，T2 必须等待 T1 释放 X 锁才可以，因为 X 锁与任何的锁都不兼容。共享锁和排他锁的兼容性如下所示：

间隙锁( gap lock )

间隙锁锁住一个间隙以防止插入。假设索引列有2, 4, 8 三个值，如果对 4 加锁，那么也会同时对(2,4)和(4,8)这两个间隙加锁。其他事务无法插入索引值在这两个间隙之间的记录。但是，间隙锁有个例外:

• 如果索引列是唯一索引，那么只会锁住这条记录(只加行锁)，而不会锁住间隙。
• 对于联合索引且是唯一索引，如果 where 条件只包括联合索引的一部分，那么依然会加间隙锁。

next-key lock

next-key lock 实际上就是 行锁+这条记录前面的 gap lock 的组合。假设有索引值10,11,13和 20,那么可能的 next-key lock 包括:

(负无穷,10]

(10,11]

(11,13]

(13,20]

(20,正无穷)

在 RR 隔离级别下，InnoDB 使用 next-key lock 主要是防止幻读问题产生。