对InnoDB隔离模式对MySQL的使用性能的影响
在这篇文章中，我将讨论一个主题——InnoDB事务隔离模式，他们的关系与MVCC（多版本并发控制），以及它们如何影响MySQL的性能。MySQL手册提供了MySQL支持的事务隔离模式的适当描述。我不会在这里重复，而是关注性能的影响。
序列化 u2013这是最强的隔离模式。从本质上说，它失败了锁管理（设置锁是非常昂贵的）。多版本控制锁定所有选项，造成大量开销和并发性。此模式只在MySQL应用程序中的一个非常特殊的情况下使用。
可重复读-这是默认的隔离级别，这通常是很好的，是为应用程序的便利性好。它读取所有数据在第一时间（假设标准未锁定），但它有一个高价格，InnoDB需要保持交易记录，它将从开始记录，其成本是非常昂贵的。更严重的是，程序经常更新的热排-你真的不想要innodb处理行，有数百数千的版本。
在性能方面，阅读和写作都会受到影响。对于MySQL 5.6中的更新，尤其是版本控制，它似乎引起了严重的争论。
下面是一个例子：开始交易运行在内存中的数据集中，过，运行整个表扫描和查询几次，并保持同时交易。
过num threads = 64————报告间隔= 10 -最大的时间= 0 = 0 -最大的请求--兰德型=帕累托= 80000000，OLTP表大小的MySQL用户=根-- MySQL密码=————= sbinnodb MySQL数据库测试= / usr / / /过分享文档/测试 / / update_index.lua分贝-- MySQL DB = sbinnodb。
正如您所看到的，写入（写入）操作的吞吐量大大降低，并且继续下降。事务是开放的，不仅当查询（查询）操作正在运行时。在读隔离模式中，当您选择了外部事务时，下一个是长事务，这可能是我能找到的最坏的情况。当然，在其他情况下，您也会看到回归算法（回归）。
如果有人想测试，您可以重复我使用的下列查询集合：
选择AVG（长度（C））从sbtest1；
开始；
选择AVG（长度（C））从sbtest1；
选择睡眠（300）；
承诺；
It is not only the default isolation level of Repeatable Read, but also can be used for InnoDB logical backup -- mydumper or mysqldump – single-transaction.
这些结果表明，备份方法太长，不能用于大数据集，这种方法也受到性能的影响，不能用于频繁写（写）的环境中。
读提交模式非常类似于可重复读取模式。区别在于，版本不读事务，而不是从当前语句读。所以使用这种模式允许InnoDB保持几个版本少，尤其是如果你不有一个很长的语句来运行。如果你有一个很长的选择要运行，例如，报告查询仍然有性能造成严重影响。
通常，我认为做好事是做阅读承诺隔离模式为默认，并改变它的应用程序或交易可重复读。
未提交读-我认为这是最难理解的隔离模式（悲伤的只有2个文件），只描述了视图的逻辑。如果你使用这个隔离模式，你将看到在数据控制所有的变化，甚至还未提交的事务。这一良好的隔离模式的情况是，你可以看到一个脏读大更新语句（脏读），显示哪条线路已经改变，并没有改变。
如果事务在运行时出错，此语句将显示未提交和未提交的更改，因此使用此模式要小心。有些用例不需要我们的100%个精确数据，在这种情况下，这种模式变得非常方便。
那么，从性能的角度来看，你是如何体现读写的呢在理论上，我们可以清晰的线条版，也可以创建在未提交读模式甚至在声明中已经执行。在实践中，声明仍然是一个行版本由于bug或一些复杂的实现细节不做。所以，如果你运行一个长期选择在未提交读宣言，你会得到很多线创造的信息，就像你使用READ COMMITTED。这里没有赢。
从选择方面的又一个重要赢未提交读隔离模式，InnoDB不需要检查老版本的最后一行永远是正确的，这将使性能显著提高，尤其是当撤销空间已经洒在磁盘，找到旧版本会导致很多读IO写。
也许上面选择AVG（K）从sbtest1就是最好的例子，我可以找到，可以类似于更新的工作量。如果未提交读隔离模式在一分钟左右，我想是不是在已提交读隔离方式完成，因为新的索引条目到更快的扫描速度。
最后认为：InnoDB隔离模式的正确使用能获得最佳性能的应用程序，你得到的好处可能是不同的，在某些情况下，它不可能是非常不同的。InnoDB的历史版本似乎有很多工作要做，我希望在未来的MySQL解决它。