MYSQL innodb_deadlock_detect 打开数据库性能低,与事务回滚

最近在重新整理MYSQL 8的MY.CNF 的配置, 在和组员讨论的试试,我们的MYSQL DBA 提出一个问题, innodb_deadlock_detect 和 innodb_rollback_on_timeout, 以及事务回滚的问题.

这里需要明确的几个问题

1  innodb_deadlock_detect 是检测死锁的一种方法,从mysql 5.7.13引入的, 在官方MYSQL 8.0 的文档中提到在高并发的系统中还是建议不使用 innodb_deadlock_detect.

大部分文字都在重复一个观点,高并发使用死锁的检测,会引起性能的问题

那么基本上每个文字都在描述打开这个开关会影响性能,到底影响那些性能了

___________________________________________________________________________

在源代码的文档里面针对这个参数有这样一个描述, 在打开这个参数后会使用

lock_get_mode_str 这个操作  下面是调用这个操作的解释

以上的代码解释来源于 MYSQL 8.023 这个版本.

时间和精力的关系不想在弄下去,检测死锁的确是比不检测要耗费性能是一定的, 某篇关于这个参数打开后的性能测试的帖子中提到  lock_detect_recursive function 是性能的罪魁祸首.

另外需要注意的是 innodb_deadlock_detect 默认是打开的状态,需要在配置文件中关闭.

那么关闭后死锁的解决方式就变成通过 innodb_lock_wait_timeout 的方式默认的wait timeout 是50秒. 

如果是OLTP 系统则建议,将这个值调的尽量小一些,而不是大,这样有利于OLTP 系统快速的解决问题,将问题回馈给应用程序,做下一步的处理,而不是HOLD在哪里.

那么下面的连锁的问题就来了, 如果死锁,其中一个事务回滚, 则根据MYSQL 默认的原则,只回滚最后的一条语句,而不是将所有的事务都回滚.

说到最后我们来捋一捋, 关于死锁以及事务回滚的MYSQL的配置我们是怎么做的

1  innodb_deadlock_detect = off

2  innodb_lock_wait_timeout = 1

3  innodb_rollback_on_timeout = on

这样配置的MYSQL 后,

1  在高并发的时候, innodb_deadlock_detect 影响性能的隐患解除了

2  我们可以根据系统的特性来设置 innodb_lock_wait_timeout 来针对不同的需求

3  设置innodb_rollback_on_timeout 设置后,整体的事务的原子性得到了保证.