在数据库系统中，死锁问题几乎是不可避免的，一般要么是资源互相占用导致，或者是系统内部的锁升级（在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
需要注意的是，你必须谨慎的使用这个功能，最好在满足几个条件才应去尝试：
- 你的业务需要确保死锁极少
- 你的业务确实有这方面的需求，经过充分的测试并确实能获得提升
- 如果非要开启这个功能，当真的发生死锁时，只能到锁等待超时才能回滚，因此记得调小
innodb_lock_wait_timeout
