在数据库系统中，死锁问题几乎是不可避免的，一般要么是资源互相占用导致，或者是系统内部的锁升级（在innodb内尤其普遍），尤其是糟糕的未经审查的SQL设计通常是导致死锁的元凶。在MySQL InnoDB引擎中，死锁的检测是通过深度遍历进行的，每一个需要等待的行锁请求都需要去检测是否可能产生死锁。

关于InnoDB事务锁，可以参阅我之前的一篇博客，这里不展开讨论:MySQL · 引擎特性 · InnoDB 事务锁简介

死锁检测是一个成熟的数据库系统必不可少的功能，但是！如果我们的应用SQL经过了充分合理的设计和验证，能够杜绝绝大部分死锁场景，这样的开销是否是可以避免的呢？

一个典型的场景是秒杀，也就是大量更新落到同一行记录上，此时大量请求同一个记录的排他行锁，导致了很长的等待队列，而死锁检测会去查询整个队列，而在整个过程中，一些全局资源（如lock_sys mutex）会被持有。为了避免检测深度过长的问题，InnoDB默认的最大检测深度为200，当超出时，会打印出死锁信息并结束死锁检测。

在阿里秒杀的场景随处可见，事实上在2012年双十一之前，我们修改MySQL的第一个补丁就是关闭死锁检测，代码量很小，就那么几行代码，带来的效果还不错。（当然这只是我们优化秒杀高并发负载场景下的第一步，远不能满足这几年的业务需求，后来我们进行了一系列的优化措施来改善MySQL以满足需求，我的同事们在不同的场合都提到过，这里我不展开说了）

在MySQL5.7.15版本开始，以及MySQL8.0.0版本，终于把这个特性加上了，增加了新的开关innodb_deadlock_detect来禁止死锁检测。

这里简单的测试下，MySQL版本为8.0.0(在该版本刚发布就把自己的5.7测试环境覆盖掉了，懒得重装了..)，使用sysbench，autocommit的单行更新

关键配置：

innodb_thread_concurrency = 32
sync_binlog = 1000
innodb_flush_log_at_trx_commit = 2

测试数据为TPS(RT ms):

Threads	Turn On	Turn Off
16	8200(2.0ms)	8300(2.03ms)
32	7900(4.32ms)	8100(4.23ms)
64	7600(9.21ms)	7800（9.13ms）
128	4950(28.7ms)	7200（19.28ms）
256	1870 (147.8ms)	6145(48.8ms)
512	442 (1169ms)	4389(129.9ms)
1024	78 (16000ms)	3000（385ms）

从测试可以看到，低并发下基本上性能没啥并发，而在高并发下，TPS和RT则有明显的改善。在该测试中，当达到1024个并发时，实例已经完全不可用了，但关闭死锁检测后，实例依然能够提供3k的TPS

需要注意的是，你必须谨慎的使用这个功能，最好在满足几个条件才应去尝试：

1. 你的业务需要确保死锁极少
2. 你的业务确实有这方面的需求，经过充分的测试并确实能获得提升
3. 如果非要开启这个功能，当真的发生死锁时，只能到锁等待超时才能回滚，因此记得调小innodb_lock_wait_timeout