如何解决 MySQL 死锁问题？（完结）

使用 MySQL 的过程中，大概率上都会遇到死锁问题，这实在是个令人头痛的问题。今天二哥就来对死锁进行一个详细地分析，并结合常见的死锁案例进行探讨，同时，给出一些如何去尽可能避免死锁的建议，希望能给球友们一些帮助和启发。

什么是死锁

死锁是并发系统中一个常见的问题，同样也会出现在数据库 MySQL 的并发读写请求场景中。

当两个及以上的事务，都在等待对方释放已经持有的锁，或因为加锁顺序不一致造成循环等待锁资源的时候，就会出现“死锁”。

常见的报错信息为 Deadlock found when trying to get lock...。

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

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

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

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

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

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

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

共享锁和排他锁的兼容性如下所示：

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

真诚点赞诚不我欺