![]()
最近在重新整理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 设置后,整体的事务的原子性得到了保证.
![]()
