浅谈InnoDB隔离模式的使用对MySQL性能造成的影响

在这篇文章里我将讨论一个相关的主题 – InnoDB 事务隔离模式，还有它们与MVCC（多版本并发控制）的关系，以及它们是如何影响MySQL性能的。

MySQL手册提供了一个关于MySQL支持的事务隔离模式的恰当描述 – 在这里我并不会再重复，而是聚焦到对性能的影响上。

SERIALIZABLE – 这是最强的隔离模式，本质上打败了在锁管理（设置锁是很昂贵的）的条件下，多版本控制对所有选择进行锁定造成大量的开销，还有你得到的并发。这个模式仅在MySQL应用中非常特殊的情况下使用。

REPEATABLE READ – 这是默认的隔离级别，通常它是相当不错的，对应用程序的便捷性来说也不错。它在第一次的时候读入所有数据 （假设使用标准的非锁读）。但是这有很高的代价 – InnoDB需要去维护事务记录，从一开始就要记录，它的代价是非常昂贵的。更为严重的情况是，程序频繁地更新和hot rows – 你真的就不想InnoDB去处理rows了，它有成百上千个版本。

在性能上的影响， 读和写都能够被影响。用select查询遍历多个行是代价高昂的，对于更新（update）也是，在MySQL 5.6中，尤其是版本控制看起来导致了严重的争用问题。

下面是例子：完全在内存中的数据集中运行 sysbench，并启动 transaction 、运行全表、扫描、查询几次，同时保持 transaction 是开着的：

sysbench --num-threads=64 --report-interval=10 --max-time=0 --max-requests=0 --rand-type=pareto --oltp-table-size=80000000 --mysql-user=root --mysql-password= --mysql-db=sbinnodb --test=/usr/share/doc/sysbench/tests/db/update_index.lua run

如果有人想测试，可以重复下面我用的查询集合：
 

不只是可复读（Repeatable Read）的默认隔离级别，同样也可以用于InnoDB 逻辑备份 –  mydumper 或者 mysqldump –single-transaction

这些结果显示这个备份的方法恢复的时间太长而不能用于大型数据集合，同样这个方法受到性能影响，也不能用于频繁写入（write ）的环境中。

READ COMMITTED 模式和REPEATABLE READ模式很相似，本质区别在于哪个版本都不在transaction中从头开始读取，取而代之的从当前语句开始读取。因此使用这种模式允许InnoDB少维护很多版本，特别是你没有很长的statements要允运行。如果你有很长的select要运行，如报表查询对性能的影响仍然很严重。