一、问题由来

前段开发反馈时间线上数据库老是出现死锁情况，而我们设置了innodb_print_all_deadlocks，但是在

相应的时间点没有找到任何相应的死锁的信息，从而导致我们获得任何有用的信息，也不能定位问题的

原因。

二、问题思考和分析

后来开发将出错码发给我，我看到这个错误码确实是MYSQL报出来的如下：

那么能够肯定一点这个死锁是MYSQL报出来的。那么为什么innodb没有任何表示呢？难道是什么BUG

继而在

找了一下BUGS也没有找，后来我思考这个问题，既然是死锁就会是相应的死锁检测算法抛出来，我们知道MYSQL

上层还有MDL LOCK，并不是只有innodb相应的lock才会有进行死锁检测，会不是因为MDL LOCK死锁照成的呢？

我在MDL.CC中找到了如下代码其实也是我上文说的MDL_context::acquire_lock 函数，上文说过这个函数是

根据MDL_REQUEST尝试获得MDL LOCK的主要函数。

点击(此处)折叠或打开

注意红色部分，其实这里死锁问题基本确定不是innodb层触发的，既然不是innodb下层触发，innodb当然不会打印

出任何信息。为什么innodb层不打印死锁信息的原因找到了，但是什么情况下会出现MDL LOCK的死锁呢?

三、问题定位

既然要产生死锁必须满足一些条件：

1、至少2个独立的线程(会话)。

2、单位操作中包含多个相对独立的加锁步骤，有一定的时间差

   比如一个事物里面的多个操作

   还比如repeat操作(虽然非常段也是有的)。 关于replace的死锁问题参考我的文章如下：

3、多个线程(会话)之间加锁对象必须有相互等待的情况发生，并且等待出现环状。

顺便提一句，死锁一般处理方式有3种

A、事前预测

B、资源分级

C、事后检测释放

而MDL LOCK和INNODB都使用了C时候检测释放，其算法应该是利用图的(DSF or BSF)遍历进行判定，这一块以后要好好看一下。

那么我考虑到使用MYSQLDUMP进行的备份的时候可能出现一些MDL LOCK的情况，比如加上-F, --flush-logs  --single-transaction会

短暂的使用 flush table with read lock;

如下：

如前文所述这个操作会在GLOBAL上加一把S锁

而导致所有的需要在GLOBAL上加IX锁的操作全部等待比如(DML操作/DDL操作)，但是这里的flush table with read lock

并不符合上面描述的死锁产生的条件，不管如何先检查一下是不是MYSQLDUMP的问题，这一检查真的检查到了问题，我们

MYSQL备份的时候，进行了一次单独的表结构的备份，同事认为很快而没有加--single-transaction，然后检查备份结束的

时间，基本和死锁出现的时间点一致，那么问题转为如果不加--single-transaction，MYSQLDUMP如何加锁。

实际上这个时候从general日志来看，加锁如下：

我的dumptest数据只有两个表kkkk和llll，我们可以看到mysqldump通过LOCK TABLES `kkkk` READ ,`llll` READ 进行加锁，

备份完成后使用unlock tables解锁。其实这就是问题的根本原因。它会照成MDL死锁的产生。如果加上--single-transaction 则不会，

会使用SET SESSION TRANSACTION ISOLATION LEVEL REPEATABLE READ改变隔离级别为RR使用事物来保证数据的一致，

而不是LOCK TABLES来保证数据的一致性。

四、模拟MDL死锁和兼容性分析

首先我们需要看一下 LOCK TABLES a READ ,b READ 到底加了哪些MDL LOCK，这个通过我在MDL.CC中加入的打印函数my_print_ticket可以看到(具体在上文)

如下：

我们可以清楚的看到本语句会对a和b分别调用函数MDL_context::acquire_lock进行加锁为object的SRO MDL锁类型，虽然是一个语句但是加锁却是分开的，

对于SRO锁兼容性如下

可以看到SRO和SW\SNRW\X均不兼容，也就是和DML(SW)\SNRW(LOCK TABLE WRITE)\X(DDL) 不兼容。

如果有另外一个事物需要对a和b进行DML操作，那么MDL 死锁出现了如下：

现在我们来分析一下

线程1

获得MDL LOCK 如下：

GLOBAL先不考虑，可以看到会在b表上获得SW的object mdl lock.

线程2

我们可以清楚的看到a表上的SRO获得成功，但是b表上的MDL LOCK 需求则进入了MDL_LOCK WAIT QUE等待了

及由于b表已经被线程1的insert语句拿到了SW锁，线程2想要获得b表的SRO锁需要等待

线程1

再次执行

我们这里线程1想要获得a表的sw mdl lock，但是线程2持有a表的SRO mdl lock，显然他们不兼容，死锁出现(VICTIM)

MDL死锁出现后根据一个权重来进行回滚如下：

虽然没有研究死锁检测的原理，但是这里应该是带权重的一个图，回滚权重小的操作。最后线程1的事物操作被回滚了。

从打印来看事物回滚后，LOCK TABLES a READ ,b READ ;获得了全部的SRO MDL LOCK成功了，打印如下：

总结一下这里的死锁

线程1 获得b的SW MDL LOCK-->线程2 获得a的SRO MDL LOCK，而拿不到b的SRO MDL LOCK(堵塞)-->线程1 拿不到a的SW MDL LOCK(堵塞)

这样 线程1和线程2都堵塞了，根据MDL LOCK死锁图的权重释放 线程1因为它都是DML操作。

五、处理

知道原因处理就相对简单了，备份表结构也加上 --single-transaction就好了，虽然备份表结构时间很短，但是高压力下也会出现死锁的情况。

也许你已明白，但对一个人有用也是我存在的理由！^_^ By:持之以恒的大白

-- 来自：