MySQL学习分享--trx_sys事务锁之争

基于《MySQL学习分享--MySQL 5.7性能改进》文中提到的事务锁的优化，MySQL在5.6之前，trx_sys事务锁一直是影响性能的主要因素。在应用中也会经常发现系统资源利用不起来，追查的结果往往是trx_sys事务锁的原因。根据以上线索，继续探索MySQL的事务的改进之路和性能之争。

4、《trx descriptors: MySQL performance improvements in Percona Server 5.5.30-30.2》

在Percona的5.5.30版本中，对MySQL事务锁性能低的原因进行了详细描述，具体如下。大体意思是说，innodb在每个事务中，需要扫描当前已经打开的事务列表trx_list，并拷贝没有提交的事务ID。在扫描事务列表trx_list时，会使用kernel_mutex加锁，这也是性能的最大瓶颈之处。

Whenever a connection wants to create a consistent read, it has to make a snapshot of the transaction states to determine which transactions are seen in  the view later. To this end, InnoDB scans trx_list (i.e. the list of currently open transactions) and copies IDs of transactions that have not yet been committed at  the current point in time, and thus should not be visible in the consistent read. For the REPEATABLE_READ isolation level, the snapshot is created on the first  SELECT for each transaction. For lower isolation levels it is created for each SELECT, even within the same transaction.

   基于以上发现，对扫描事务列表进行了优化，减少了扫描和拷贝，提高MySQL的性能。并且文中指出，MySQL 5.6虽然在trx_sys事务锁方面进行了大量的改进和优化，但只是在只读事务场景下，并且需要业务在启动只读事务时，调用START TRANSACTION READ ONLY命令，这样在SELECT查询时，才会不被加锁。

接下来的测试，也表明Percona 5.5.30版本进行的优化，在QPS方面优于官方版本，但低于MySQL 5.6.2版本；在TPS方面也优于官方版本甚至MySQL 5.6.2版本。

5、《MySQL Performance: Analyzing Benchmarks, part 4: TRX list》

该文是上一篇文章的回击，主要针对上一篇文章的测试结果进行进一步的验证，文中指出MySQL 5.6与Percona 5.5.30版本相比，性能优势明显。由于Percona 5.5.30版本基于MySQL 5.5，trx_sys事务锁仍然存在，并且随着线程数的增加，事务锁会不断增加，并没有根治trx_sys问题。但是MySQL 5.6自身仍然存在很大的性能问题，在CPU cores增大时，trx_sys仍然会迅速增加，但是性能仍然优于Percona 5.5.30。测试同时引入了MariaDB 5.5进行了测试，测试结果远远低于MySQL 5.5和Percona 5.5.30。

通过测试结果，最终的结论是MySQL 5.6远远高于Percona 5.5.30，并没有上一篇文章测试结果中Percona 5.5.30的性能优势。

6、《More on MySQL transaction descriptors optimization》

根据上文的质疑，文章5的作者进行了进一步的验证，统一硬件和数据集的问题，验证两个版本的性能差异。测试包括两个部分：首先使用NUMA，排除HT超线程的影响；通过硬件CPU core的不同，进行性能测试。最终测试结论是：Percona 5.5.30优于MySQL 5.6.10。其中一个细节，测试中的内存管理方式都是使用jemalloc，而不是glibc的malloc内存管理方式。关于内存管理方式的性能测试，可以参考之前对jemalloc的测试。

此外，文中指出，MySQL 5.6性能优势只能在完全的RO只读事务场景下，此时的trx_list为空。但是场景过于理想，并不满足应用环境。于是进行了读写事务9:1混合模式下的测试，测试结果表明，MySQL 5.6在读写混合模式下，性能远远低于Percona 5.5.30。

7、《MySQL Performance: Analyzing Benchmarks, part 5: TRX list again》

针对上一篇文章的回击，本文进行了进一步的验证测试，测试内容从两个角度进行：不同的CPU core下HT超线程的性能情况；相同条件下，数据库的性能比较；在SELECT事务场景下不同并发条件的测试；读写模式下的性能测试。

Percona 5.5.30和MySQL 5.6在CPU为16 HT情况下，性能达到最优，在CPU core为32以及32 HT情况下，性能反而更差。从这个角度来说，努力提高硬件的性能，不一定能够获得更高的MySQL数据库性能，这个在机器选型测试时，还是要进行周密的考虑。

在16 HT性能最优的场景下，Percona 5.5.30仍然会有较多的trx_sys事务锁影响，并且测试的性能来看，Percona 5.5.30仍然有大量的kernel_mutex锁，并且性能上仍然远远低于MySQL 5.6。

SELECT事务场景下，MySQL 5.6的性能影响较大，远远不如Percona 5.5.30。但是Percona 5.5.30测试中也暴露了kernel_mutex锁影响较大，而在MySQL 5.6中已经移除。

在读写混合模式下，测试中引入了Percona 5.6，测试结果表明，Percona 5.6基于MySQL 5.6进行改进，性能优势明显。从而验证MySQL 5.6的trx_sys优化方式的有效性，却没有对Percona版本进行采用，原因是没有完全解决trx_sys问题。并透露，在MySQL 5.7中，会优化trx_sys，提高在RW读写场景下，MySQL数据库的性能。

结论

通过以上MySQL的trx_sys事务锁之争，总结如下：

1、MySQL 5.6在RO场景下，通过start transaction read only声明为只读事务，性能提高较大。而在事务模式下，性能无明显优势。

2、Percona 5.5.30在trx_sys上的改进，不仅提高了RO只读环境下MySQL的性能，而且提高了RW读写混合场景下的性能。

3、Percona 5.6基于MySQL 5.6的改进，适合RW场景，性能优势明显，是目前最佳的方案。

4、CPU core为16 HT下，Percona5.5.30和MySQL 5.6的性能达到最佳，提示我们努力提高硬件的性能，不一定能够获得更高的MySQL数据库性能。在机型选择时，需要进行测试和验证。

5、MySQL 5.7在trx_sys上的巨大改进，适应RW读写场景，降低事务锁，值得期待。

参考

1、《trx descriptors: MySQL performance improvements in Percona Server 5.5.30-30.2》：http://www.mysqlperformanceblog.com/2013/04/12/trx-descriptors-mysql-performance-improvements-in-percona-server-5-5-30-30-2/

2、《MySQL Performance: Analyzing Benchmarks, part 4: TRX list》：http://dimitrik.free.fr/blog/archives/2013/04/mysql-performance-analyzing-benchmarks-part-4-trx-list.html

3、《More on MySQL transaction descriptors optimization》：http://www.mysqlperformanceblog.com/2013/04/26/more-on-mysql-transaction-descriptors-optimization/

4、《MySQL Performance: Analyzing Benchmarks, part 5: TRX list again》：http://dimitrik.free.fr/blog/archives/2013/07/mysql-performance-analyzing-benchmarks-part-5-trx-list-again.html

5、《MySQL性能测试--jemalloc内存管理》：http://blog.chinaunix.net/uid-26896862-id-3865087.html