为何MySQL遇到死锁后未等待超时时间，直接返回？

代码原运行与Oracle数据上，后切换到MySQL。

测试发现，存在死锁问题，且遇到死锁直接报错，并没有等待数据库默认的50S超时时间。

Caused by: 
com.mysql.jdbc.exceptions.jdbc4.MySQLTransactionRollbackException: 
Deadlock found when trying to get lock; try restarting transaction

起初以为是不是超时时间被人改了？

查看后发现并没有改变。

SHOW global VARIABLES LIKE 'innodb_lock_wait_timeout';

 

后来了解到mysql在5.7以后增加了innodb_deadlock_detect这个全局变量，默认为ON。这个变量用于控制MySQL是否主动检测死锁。

死锁检测的原理是构建一个以事务为顶点，锁为边的有向图，判断有向图是否有环，如有，即死锁。

检测到死锁后，会选择插入更新或删除的行数最少的事务回滚，基于 INFORMATION_SCHEMA.INNODB_TRX 表中的 trx_weight 字段来判断。

 

遇此次，遇到死锁后未等待超时时间，直接返回的原因估计就是它了。

总结：

MySQL有两种死锁处理方式：

1、innodb_lock_wait_timeout，设置超时时间，默认50S。

2、开启死锁检测，如果检测到回滚一条事务，继续其他事务。

但死锁检测的做法有一个性能问题：

对比的时间复杂度是O(n)。如果有1000个正在执行的线程，就存在100w次的对比，消耗CPU资源极大。

有博主做过压测，开启死锁检测大约存在5%左右的性能损耗。

---

在刚开始也想过死锁是否和事务隔离级别有关系，当时使用的RR级别，后来在官方文档看到一句话

The possibility of deadlocks is not affected by the isolation level, 
because the isolation level changes the behavior of read operations, 
while deadlocks occur because of write operations.

https://dev.mysql.com/doc/refman/5.7/en/innodb-deadlocks.html

至于死锁的原因，通过explain发现，很可能是某句造成了全表扫描，进而造成了表锁。