【译】MySQL 5.7中InnoDB事务隔离模式的影响
via
过去几年,其他人已经写了很多有价值的文章,解释了InnoDB事务隔离级别的所有细节以及如何解决这个问题。因此,我将避免重复已经说过的内容; 我的注意力吸引了PeterZ的性能研究并发表在以下文章中:https://www.percona.com/blog/2015/01/14/mysql-performance-implications-of-innodb-isolation-modes/ 这篇文章非常好,可以很好地分析观察问题所在,可以通过修改隔离级别为READ-COMMITTED替代REPEATABLE-READ(InnoDB默认级别)来解决。那么问题来了:为什么我们没有默认的READ-COMMITTED模式?有什么危险吗?
让我们一起探讨
首先,你应该记住你的理论,不仅仅是在InnoDB中实现所有这些东西的方式:
- InnoDB中的事务隔离/ MVCC是通过ReadViews实现的
- 每次创建ReadView时,都应该获取互斥锁(trx_sys)
- 在REPEATABLE-READ模式下,在事务启动时创建ReadView
- 在READ-COMMITTED模式下,在每个语句上创建一个ReadView
- 意味着,如果您的陈述很短 - 您可能会在工作负载中遇到trx_sys互斥争用风暴。
当然,一切都取决于工作量,如果你很幸运,你可能会在这里看到一个好处(一切皆有可能,对吧? - 至少在理论上)
现在让我告诉你一些你会觉得自己不那么幸运的情况
对于我的测试用例,我将使用:
40cores-HT服务器
运行OEL 6.5 2.6.32-504内核
极快的闪存(Fusion-io ioMemory)
每个工作负载使用64个并发用户
每个工作负载执行3个测试用例:
配置REPEATABLE-READ模式(RR)
READ-COMMITTED模式已配置(RC)
已配置READ-UNCOMMITTED模式(RU)
DBT-2 500W工作负载(TPC-C):
观察 :
你可能已经观察到,与第一个(RR)相比,第二(RC)和第三(RU)测试案例的TPS略低一些
“回归”不是很大,但值得注意
现在让我们来看看InnoDB中的内部锁定争用。
锁定争议:
观察 :
对于RC和RU测试,trx_sys互斥锁的跳跃争用非常明显
然而,它还不是太大,不会造成严重的损害..
现在,让我们转移到一个沉重的Sysbench OLTP_RW - 我在这里通过在我的测试中添加读/写比率稍微改变了“经典”OLTP_RW:
最初负载以128:1的比率开始(主要是读取,少写入)
那么16:1
那么4:1
那么2:1
最后1:1
我也在使用这个测试用例来评估写入在事务中的影响等。
到目前为止:
Sysbench OLTP_RW 32x10M-tables,rw128 / 16/4/2/1:
观察 :
这里的影响更多只是值得注意的;-)
这只是因为trx_sys互斥争用?或者是其他东西?..
锁定争议:
观察 :
哦,确实,trx_sys现在跳得太高了!
它会更糟糕吗?
让我们看看;-)
下一个工作负载的代码名称是“OLTP_RW-p_sel10” - 这个测试中的所有读取都被10个点选择所取代,这就是全部,使得写入时的负载更加激进,读取时更快和更快:
Sysbench OLTP_RW-p_sel10 32x10M表,rw128 / 16/4/2/1:
观察 :
事实上,看到x2时间更糟糕的表现真的是杀人..
仍然由于trx_sys互斥?
锁定争论:
嗯,你可能仍然会说这只是因为这个服务器太大了,这就是我观察所有这些争论的原因,你将离现实不远 - 在较小的机器上所有这些争论当然都会降低 - 但是!仍然“值得注意”;-))
相同的OLTP_RW-p_sel10,但在20cores-HT上:(
虽然今天许多x2 CPU Intel机器总共拥有超过32个-cx-HT,所以“小”HW变得很大; - ))
总结:
那么,我们最终应该从所有这些东西中得出结论?
PeterZ告诉我们一个如此美好的故事,现在你带着你的实验来表明PeterZ错了……
伙计们,PeterZ没错!
?? - 所以,你在撒谎??????
而且我也不是在撒谎;-))
??? …..
那么,你应该记住的是,没有“银弹”,大多数情况下最普遍的答案将是“它取决于” ;
与InnoDB交易隔离在这里是一样的故事!
一般规则如下:
如果您的查询和事务很短:请使用默认的REPEATABLE-READ模式!
如果您的查询很长并且读取了很多可能被其他事务并行修改的数据:那么使用READ-COMMITTED模式 - 这将允许您在查询进行时读取已提交的更改并避免丢失而不是扫描旧页面图像(正如PeterZ在他的故事中向你展示的那样;-))