MariaDB 10.1 和 MySQL 5.7.4-labs-tplc 的性能评估
引言
评估数据库系统的性能是一项非常艰巨的任务。需要做出很多艰难的选择，例如：
- 使用什么操作系统及版本
- 使用什么配置设置
- 使用什么基准测试以及预热和测量时间多长
- 使用什么测试设置
- 使用什么版本的数据库管理系统
- 使用什么存储引擎
虽然性能评估主要是机器时间，但人类监控测试仍然需要大量艰苦的工作。在这篇博文中，我们做出了以下选择：
- 我们使用了一颗 Intel Xeon E5-2690 @ 2.9GHz CPU，包含 32 个核心，运行 Linux 3.4.12，拥有 132GB 主内存。数据库存储在 Fusion-IO ioDrive2 Duo 2.41TB 固件 v7.2.5，版本 110646 上，使用驱动程序 3.3.4 版本 5833069。数据库文件系统使用 NVMFS，所有测试日志和输出存储在 EXT4 上。
- 我们选择了以下基准测试：
- LinkBench [1]，它基于 Facebook（一家主要社交网络）存储社交图数据生产数据库的跟踪记录。LinkBench 为社交和 Web 服务数据的持久存储提供了现实且具有挑战性的测试。
- Percona 提供了一个在线事务处理 (OLTP) 基准测试，它是类似 TPC Benchmark C [2] 工作负载的实现，模拟仓库应用。TPC Benchmark C 于 1992 年 7 月获得批准，是一个在线事务处理 (OLTP) 基准测试。TPC-C 比之前的 OLTP 基准测试（如 TPC-A）更复杂，因为它具有多种事务类型、更复杂的数据库和整体执行结构。TPC-C 涉及混合执行五种不同类型和复杂度的并发事务，这些事务既可以在线执行，也可以排队延迟执行。数据库由九种类型的表组成，记录和填充大小范围广泛。TPC-C 以每分钟事务数 (tpmC) 为单位进行衡量。
- 我们使用 LinkBench 数据库大小为 10 倍，即约 100GB，TPC-C 仓库数量为 1000 个。InnoDB 缓冲池设置为 50GB，因此在这两个基准测试中，数据库都无法完全放入主内存中。
- 我们选择了 MariaDB 10.1.0 和 MySQL 5.7.4-labs-tplc 的 Alpha 版本，因为我们对它们的开发版本性能感兴趣。我们之所以选择这些特定版本，是因为它们都包含对 FusionIO 硬件、原子写入 [3,4] 和页压缩 [5] 的支持。
- 我们决定在测试的两个服务器上都使用 InnoDB 存储引擎。
- 我们在所有测试中都使用了 FusionIO 硬件原子写入 [3,4]。
我们选择这些的原因如下：
- 我们希望评估现代硬件的性能，而不是一些即将淘汰的旧硬件。选择的硬件是如今为数据库服务器采购新硬件时可能会使用的设备。
- 我们不想评估任何极端情况的性能，例如单线程客户端、所有数据都在主内存中、客户端线程数量过高或过低、仅读或仅写工作负载等等。这些情况对某些应用来说很有趣，但并非对所有应用都如此。
- 我们希望使用数据库社区熟知和认可的基准测试。
- XtraDB 不适用于 MySQL，我们有证据表明 XtraDB 在 FusionIO 硬件上性能不佳。
- 我们在所有测试中都使用原子写入，因为它提供了更好的性能，因此我们禁用了 doublewrite buffer，因为使用原子写入时它是不必要的。
MySQL/MariaDB 配置
我们无法为 MariaDB 和 MySQL 使用完全相同的配置文件 (my.cnf)，因为参数命名存在一些差异。因此，下面列出了配置变量的值，首先是通用变量及其值，然后是包含 MySQL 参数的 oracle 标签，以及包含 MariaDB 参数的 mariadb 标签。所有参数的选择都力求公平和具有代表性，但我们不声称它们是针对此硬件或这些基准测试的最佳值。
[mysqld] innodb_buffer_pool_size = 50G innodb_use_native_aio = 1 innodb_data_file_path=ibdata1:10M:autoextend innodb_doublewrite = 0 innodb_file_per_table = 1 innodb_flush_log_at_trx_commit=1 innodb_buffer_pool_instances = 16 innodb_compression_level = 6 #following is used for page compressed tables 2=lz4 innodb_compression_algorithm = 2 #following is used for uncompressed tables #innodb_compression_algorithm = 0 innodb_flush_method = O_DIRECT innodb_thread_concurrency = 32 innodb_write_io_threads = 32 innodb_read_io_threads = 32 innodb_file_format=barracuda innodb_lru_scan_depth=25000 innodb_io_capacity=25000 innodb_io_capacity_max=35000 innodb_flush_neighbors=0 innodb_adaptive_flushing=1 innodb_log_buffer_size=256M innodb_log_files_in_group=2 innodb_log_file_size=8GB [oracle] innodb_compression_punch_hole = 1 [mariadb] innodb_use_fallocate = 1 innodb_use_atomic_writes = 1 innodb_use_trim = 1 ignore-builtin-innodb plugin-load=ha_innodb.so plugin-dir=/usr/local/mysql/ #these are used on MariaDB page compressed tables, not so good on other configurations innodb_mtflush_threads = 16 innodb_use_mtflush = 1
基准测试设置
如前所述，LinkBench 使用 10 倍数据库大小，这将创建约 100GB 的数据库。加载命令如下：
./bin/linkbench -D dbid=linkdb -D maxid1=100000001 -c config/MyConfig.properties -l
LinkBench 测量阶段使用 64 个客户端线程，我们使用 maxtime 86300 秒，即 24 小时，预热时间默认为 180 秒。测量命令如下：
nohup ./bin/linkbench -D requesters=64 -Dmaxid1=100000001 -c config/MyConfig.properties -D requests=500000000 -D maxtime=86300 -r
对于 TPC-C，我们使用 1000 个仓库，因此加载命令如下：
sh -x load.sh tpcc1000 1000
我们使用默认线程数，即 64 个客户端线程（除非另有说明）。我们运行 TPC-C 的时限为 10800 秒，即 3 小时，预热时间为 30 秒，即测量命令如下：
./tpcc_start -dtpcc1000 -u root -w1000 -c64 -r30 -l10800 > res
性能结果：LinkBench
两个服务器都包含对 FusionIO 硬件的原子写入 [3,4] 和页压缩 [5] 的支持。下面我们比较使用此功能报告的操作数 = 事务/秒。
两个服务器在缓冲池预热并满载后都提供了稳定的性能。在两个服务器中，缓冲池满载后性能都会下降，这时我们需要从 FusionIO 硬件中真正获取页面。然而，MariaDB 在缓冲池满载后提供了明显更优的性能。在此测试中，我们使用了两个服务器都提供的 LZ4 压缩方法。MariaDB 可以提供约 30% 的更好性能，测试结束时的差异为每秒 5654 次操作。
如果系统可用，两个服务器都提供以下压缩方法：
- zip https://en.wikipedia.org/wiki/Libzip
- lz4 https://en.wikipedia.org/wiki/LZ4_%28compression_algorithm%29
如果系统可用，MariaDB 还支持以下压缩方法：
- lzo https://en.wikipedia.org/wiki/Lempel%E2%80%93Ziv%E2%80%93Oberhumer
- lzma https://en.wikipedia.org/wiki/Lempel%E2%80%93Ziv%E2%80%93Markov_chain_algorithm
- bzip2 https://en.wikipedia.org/wiki/Bzip2
下面我们展示了在两个服务器上使用未压缩表得到的相同结果。
两个服务器一开始性能都很好，但当缓冲池满载且写入放大开始减缓 I/O 性能时，性能会缓慢下降。这是由于写入放大 (WA)，它可能发生在闪存和固态硬盘 (SSD) 上，其中实际写入的物理信息量是预期写入的逻辑信息量的倍数。因为闪存必须先擦除才能重写，执行这些操作的过程导致用户数据和元数据被移动（或重写）不止一次。这种倍增效应增加了 SSD 生命周期内所需的写入次数，从而缩短了其可靠运行的时间。增加的写入还会消耗到闪存的带宽（计算），这主要降低了 SSD 的随机写入性能 [6]。MariaDB 提供了约 8% 的更好性能，测试结束时的差异为每秒 2225 次操作。
下一个研究点是行压缩表。由于 MySQL 和 MariaDB 包含相同或几乎相同的实现，我们预计性能不会有显著差异。结果如下：
结果正如预期，几乎相同，观察到的微小差异显然在统计变异范围内。最后，让我们结合之前的所有结果，看看未压缩、行压缩和页压缩结果之间的差异。
正如预期的那样，使用未压缩表可获得最佳性能。请注意，此结果与 [5] 中呈现的结果并不矛盾，因为在此我们使用原子写入并在所有测试中禁用了 doublewrite buffer。在测量时间结束时，页压缩性能比未压缩性能低约 22%，差异为每秒 5500 次操作。类似地，在测量时间结束时，行压缩性能比未压缩性能低约 68%，行压缩性能比页压缩性能低约 37%。最后，未压缩和行压缩之间的差异为每秒 11800 次操作，页压缩和行压缩之间的差异为每秒 6568 次操作。
对于我们的最终测试，我们测量了使用 MariaDB 10.1 创建 10 倍大小 LinkBench 数据库所需的加载时间。
显然，创建页压缩数据库所需时间最短，其次是未压缩数据库。创建行压缩数据库比前两者慢得多。
性能结果：TPC-C
我们再次从使用页压缩功能 [5] 的 TpmC 结果开始，使用不同数量的客户端线程。
同样，MariaDB 在所有测试中都提供了明显更好的性能。使用的服务器有 32 个核心，这就是为什么当客户端线程数增加到超过 32 个核心时，性能数字会下降。让我们看看新订单事务的性能结果以及使用默认客户端线程数的结果。
虽然 MySQL 偶尔可以提供更高数量的已完成新订单事务，但其变化幅度明显更大，中位数也远低于 MariaDB 的结果。MariaDB 在缓冲池预热后可以提供相当稳定的性能。显然，MySQL 的 flush 实现无法跟上非常快的 FusionIO 硬件。本文所有测试的瓶颈不在于 FusionIO 硬件，而在于 MySQL/MariaDB 的实现。
在下图中，我们比较了使用未压缩表和页压缩表的结果，同时改变 TPC-C 测试套件客户端线程数从 4 到 512。
当客户端线程数在 4 到 32 之间时，MariaDB 在未压缩表和页压缩表上都能提供明显更好的性能。实际上，MariaDB 页压缩表的性能与 MySQL 未压缩表的性能相同甚至更好。当客户端线程数增加时，MariaDB 的性能比 MySQL 更早下降，但下降幅度不如使用 512 个客户端线程的最终结果中看到的 MySQL 性能那样显著。在高客户端线程数下，MariaDB 页压缩性能与未压缩表相比可以提供显著更好的性能。
结论
首先，这两个数据库服务器的 Alpha 版本都非常稳定。在进行性能评估期间，我们没有遇到哪怕一次崩溃或其他问题。这对这些开发版本的质量来说是一个非常好的迹象。
其次，显然需要识别和修复由显着更快的 FusionIO 存储设备引入的新瓶颈。在所有测试中，我们都未能接近充分利用 FusionIO 硬件提供的全部吞吐量。FusionIO 硬件可以被视为内存层次结构 [7] 的新级别，需要类似主内存所需的 [8] 新型优化和研究。一些早期研究成果可以在 [9] 中看到。
最后，对于具有类似于 LinkBench 和 TPC-C 所示工作负载的应用，MariaDB 显然可以提供更好的性能。
参考文献
[1] Timothy G. Armstrong, Vamsi Ponnekanti, Dhruba Borthakur, and Mark Callaghan. 2013. LinkBench：一个基于 Facebook 社交图的数据库基准测试。收录于 Proceedings of the 2013 ACM SIGMOD International Conference on Management of Data (SIGMOD ’13)。ACM, New York, NY, USA, 1185-1196. http://doi.acm.org/10.1145/2463676.2465296.
[3] MariaDB 引入原子写入，https://blog.mariadb.org/mariadb-introduces-atomic-writes/
[4] Xiangyong Ouyang and David W. Nellans and Robert Wipfel and David Flynn and Dhabaleswar K. Panda: 超越块 I/O：重新思考传统存储原语，收录于 Proceedings of the 2011 IEEE 17th International Symposium on High Performance Computer Architecture, pages 301-311, http://dx.doi.org/10.1109/HPCA.2011.5749738
[5] MariaDB 在 FusionIO 上使用新的页压缩显着提升性能，https://blog.mariadb.org/significant-performance-boost-with-new-mariadb-page-compression-on-fusionio/
[6] 写入放大。https://en.wikipedia.org/wiki/Write_amplification
[7] 内存层次结构。https://en.wikipedia.org/wiki/Memory_hierarchy
[8] Stefan Manegold, Peter A. Boncz, and Martin L. Kersten. 2000. 为新瓶颈：内存访问优化数据库架构。《The VLDB Journal》9, 3 (2000 年 12 月), 231-246. DOI=10.1007/s007780000031 http://dx.doi.org/10.1007/s007780000031
[9] Seok-Hoon Kang, Dong-Hyun Koo, Woon-Hak Kang and Sang-Won Lee: Flash Memory SSD 在 Hadoop 应用中的案例分析，
《International Journal of Control and Automation》，Vol. 6, No. 1, 2013 年 2 月。http://www.sersc.org/journals/IJCA/vol6_no1/17.pdf
你们真的在写负载很高的 I/O 密集型基准测试中使用了默认的 innodb_log_file_size 吗？这会严重损害吞吐量，而且由于你们开启了自适应刷新，这更是导致大量可避免的重复页面刷新的一个更严重的问题。MySQL 和 MariaDB 中最终的 innodb_log_file_size 是多少？我之所以问这个问题，是担心你们可能利用了这个设置在默认配置上的差异。
服务器是拥有四颗 CPU，每颗有八个核心并且禁用了超线程，从而将有效使用的 CPU 数量减半，还是拥有两颗 CPU，每颗有 16 个完整核心并且启用了超线程？假设是四颗 CPU，我会首先尝试启用超线程。
为什么在看起来能够同时运行 64 个线程的系统上使用 innodb_thread_concurrency = 32？考虑到核心似乎支持的线程数，这看起来没有帮助，尽管这确实取决于工作负载和硬件，所以它可能是正确的设置。
为什么在工作负载从未超过 32 个客户端的情况下，将 innodb_thread_concurrency 设置为非零值？考虑到除非需要限制，否则 innodb_thread_concurrency 设置为非零值通常被认为比不设置慢。
为什么在高负载的生产服务器工作负载下保留了自适应刷新，而不是将其关闭并自行调整 I/O 设置？
为什么没有将 innodb_flush_neighbors 从默认值 1 更改为 0？这是我们推荐用于类 SSD 存储的设置。将其保留为 1 是浪费 IO 并减慢不使用旋转磁盘的磁盘设置性能的好方法。
为什么将 innodb_buffer_pool_instances 从两个服务器版本的默认值 8 更改为 16？这是否增加了或减少了两者之间的性能差异，它是否是两者的最佳值，还是对其中一个最佳而对另一个非最佳？
为什么 innodb_checksum_algorithm 仍然使用默认的旧 innodb 方法，而不是 5.6 版本中引入的新的 crc32 方法？新方法是专门为了改善在像这里使用的非常快速的存储硬件上的性能而引入的，在这些硬件上发现使用 innodb 方法计算校验和可能是性能瓶颈。
为什么 MySQL 中未使用 table_open_cache_instances 设置，而 MariaDB 默认启用了类似的减少争用的设置？对于你们使用的这类硬件，我们推荐值为 16，或者手册中提到的 8 也有帮助，如果该领域的并发是一个问题的话。对于合适的工作负载，希望人们不会注意到这个缺失的设置是利用 MySQL 和 MariaDB 处理此问题的方式并利用错误配置来制造性能差异的一种方式，而有能力的 DBA 早已解决了此问题。
每个服务器的 SHOW VARIABLES 输出是什么？每次基准测试后，每个服务器的 SHOW GLOBAL STATUS 值是多少？每次运行结束后，SHOW ENGINE INNODB STATUS 的输出是什么？这是为了检查 table_open_cache 和 table_definition_cache 等设置是否过小，导致持续关闭和打开表而浪费 IO。
你们在每个服务器上都启用了或禁用了 PS，或者将其设置为相同的设置，还是决定通过在一个服务器上开启而在另一个服务器上关闭来造成劣势？
我的初步印象是，你们针对工作负载和硬件错误配置了服务器，没有做一些我期望即使是相当缺乏经验的 DBA 也会做的事情，或者解释为什么他们选择不这样做。
由于我不是一个初级 DBA，并且在通过仔细选择服务器配置和工作负载设置来操纵基准测试方面有一些经验，我也想知道这一点。
现在，这些问题都不包含任何复杂的分析，它们只是我希望许多有能力的 DBA 都会想到的问题。但这确实告诉了你，为什么我认为你们的文章对于任何认真关注 MySQL 和 MariaDB 性能差异的人来说，几乎毫无用处。这并不是说这篇文章没有成为一篇潜在有用的文章的基础，只是目前连设置都存在太多奇怪和未解释之处，以至于我无法基于它对任何性能差异产生任何有用的想法。
James Day, MySQL 高级首席支持工程师，Oracle
在两个服务器上，我使用了 innodb_log_buffer_size=256M，innodb_log_file_size=8G 和 innodb_log_files_in_group=2。将这些值设置得更大，性能差异不显著，并且差异在两个服务器上相似。瓶颈不在于 IO，正如所指出的，它在于 MariaDB 和 MySQL 服务器本身。
我使用了 innodb_thread_concurrency = 32，因为它在两个服务器上都产生了最佳性能结果。工作负载确实使用了超过 32 个客户端，TPC-C 中最大是 512，LinkBench 中是 100 个客户端线程。
我没有看到 innodb_adaptive_flushing 设置对性能有显著差异。我使用了 innodb_flush_neighbors = 0。
缓冲池实例的设置似乎对这些测试和硬件是最佳的。我测试了 0 和 64，没有看到显著差异。
如果新的 crc32 方法对性能更好，为什么它不是默认值？我不认为不同的设置对性能有渐近显著的影响，更改它对两个服务器的影响会类似（因为实现相同）。
再次，如果 table_open_cache_instances 的不同默认值有影响，为什么它不是默认值？
两个服务器上都禁用了 PS。
您是说我之所以配置错误，仅仅是因为 MySQL 显示性能较差？配置已尽可能公平。我没有时间测试所有配置变量的组合。我测试的大多数变量设置对最终结果没有显著差异。
我对 table_open_cache 和 table_definition_cache 都使用了默认值，因为两个基准测试的表都非常少。
谢谢。正如您可能已经注意到的，MySQL 的 table_open_cache 默认值比 MariaDB 更大，但我还是提到了这个潜在问题，即使它可能已经帮助您注意到 MariaDB 设置的性能问题。
所需的 table_open_cache 条目数量不仅取决于表的数量，还取决于运行中的查询打开每个表的实例数量，因此即使在只有少量表的测试中，也完全可能使用数千个 table_open_cache 条目。这也是为什么需要在测试后检查计数器输出的原因之一。
MySQL 5.5 服务器不支持 CRC 校验和计算方法。如果我们将其默认开启，用户在升级到 5.6 后将无法降级到 5.5。由于默认设置的目标受众大多不会使用 SSD 甚至更快的存储，并且也不太可能有硬件 CRC 计算支持，因此我们选择了易用性。
table_open_cache_instances 设置对于 MySQL 5.6 默认设置的目标受众来说不太可能成为问题，但它与更高负载的服务器和基准测试相关。
对不同服务器进行基准测试并不容易，所以我表示理解。
James Day, MySQL 高级首席支持工程师，Oracle
我已将遗漏的配置变量添加到正文中。我的观点是，如果我错误配置了服务器，那么我对两个服务器都这样做了。因此，如果不同的设置能提供更好的性能，那么对两个服务器的影响是相似的。如果默认值存在差异，并且不同的设置会更好，那么应该修复它。
正如其他人也观察到的，有时一个设置在其中一个中处理方式与另一个不同，并且可能在一个中需要一个选项，而在另一个中不需要。
还必须考虑默认设置的目标受众。对于 MySQL 5.6，我要求更改默认设置，从旧的微型服务器假设转变为可能占全球所有 MySQL 安装大多数的小型设置，即大量的托管和共享设置。选择不同目标受众的服务器可以选择不同的默认设置，两者都没有错，只是针对不同的目标进行了优化。
观点仅代表我个人。对于 Oracle 的官方观点，请咨询公关人员。
James Day, MySQL 高级首席支持工程师，Oracle
这有多少只是在比较 MySQL 和 MariaDB 的 FusionIO 原子写入实现？
绝大多数用户不使用 FusionIO。你们能否在非 FusionIO 的 SSD 上重新运行基准测试？
这篇文章没有比较原子写入的实现，因为原子写入是由 NVMFS 和 FusionIO 硬件处理的。两个服务器都只是发出 ioctl 并使用正常的 AIO 写入。我知道用户目前还没有使用 FusionIO，但根据这些结果，他们确实应该使用。
> 这篇文章没有比较原子写入的实现
那么文章中的这句话是什么意思？
“我们在所有测试中都使用了 FusionIO 硬件原子写入 [3,4]。”
在所有测试中，两个服务器都使用了原子写入，并且在两个服务器上都以完全相同的方式实现，即调用带有 DFS_IOCTL_ATOMIC_WRITE_SET _IOW(0x95, 2, uint) 的 ioctl()。正如博客正文中所述，刷新存在显着差异，MariaDB 可以使用多线程进行压缩和发送 AIO 请求。MySQL 没有该功能。
所以这又回到了我最初的观点：所有这些基准测试可能仅仅意味着 MariaDB 的 FusionIO 原子写入实现比 MySQL 的快。这很有趣，但对于绝大多数不使用 FusionIO 的用户来说也是无用的。
我知道您说 FusionIO 原子写入不是这次基准测试中 MariaDB 和 MySQL 性能差异的原因，但当您只使用 FusionIO 时，无法证明这一点。
更有用的做法是在非 FusionIO 的 SSD 上运行此基准测试。那将具有更高的现实世界相关性。
原子写入是 FusionIO NVMFS 的特定功能。MySQL labs 版本可以透明地将页面压缩/解压缩到支持稀疏文件 (PUNCH_HOLE) 的任何文件系统。因此，它应该可以在 EXT4、XFS 和 Windows 上工作。
我还想补充一点，MySQL labs 版本已经通过了完整的质量保证 (QA)，并且也可以在不支持 AIO 的系统上工作。可传输表空间也应该可以工作，在 labs 版本中，它将压缩所有 InnoDB 文件，包括系统表空间和 UNDO 日志。
这是企图散布虚假信息吗？带有透明页压缩的 MySQL labs 版本基于 5.7.4。正如 Laurynas 指出的，您需要使用 –innodb-page-cleaners=16 进行公平比较。请参阅 https://dev.mysqlserver.cn/worklog/task/?id=6642
您声称“MySQL 没有该功能”是错误的。labs 版本可以使用并且确实使用了 flush 线程进行压缩，并且 flush 线程可以并且确实提交 AIO 写入请求。
按照我使用的定义，这还不是基准测试。这仍然是基准营销 (benchmarketing)，直到您开始解释为什么两个系统之间性能存在差异。我知道 SkySQL 有性能专家具备这方面的才能 — http://smalldatum.blogspot.com/2014/06/benchmarketing.html
innodb_lru_scan_size 是按缓冲池实例计算的。将其设置为 25k，配合 16 个实例太高了。在这种情况下，2k 或 3k 可能更好。而“太高”可能意味着 InnoDB 后台线程使用了过多的 CPU 时间，并通过试图从 LRU 尾部查找过多页面而导致互斥锁争用。我经常感到困惑，因为 io_capacity 是总计值，而 lru_scan_depth 是按缓冲池实例计算的。
Mark，您关于 innodb_lru_scan_size 过大的说法可能是正确的，但两个服务器的设置是相同的，我回来后会修正这个设置。
为什么 MariaDB 的 innodb_mtflush_threads = 16，而 MySQL 的 innodb_page_cleaners = 1？这是一个明显的差异，尽管由于结果是以黑盒方式呈现的，很难判断其影响。
MariaDB 10.1 默认不编译 PFS。这导致了多少性能差异？
我的错，我不知道有这样的参数，我需要重新运行一些测试。
由于某些原因，我的评论第一次没有发送成功。第二次尝试
为什么 MariaDB 启用了并行刷新，而 MySQL 没有（innodb_mtflush_threads = 16 而 innodb_page_cleaners = 1）？这是两者之间最大的差异，不允许声称设置是相同的。
有多少性能差异是由于 MariaDB 默认不编译 PFS 导致的？
问题是 MySQL 没有与并行刷新完全相同的功能。如果我在 MySQL 上设置 innodb_page_cleaners=16，这就算相同的设置了吗？我不这么认为。
MySQL 也可以不编译 PFS，我将使用这些新的配置参数来尝试性能。
没错，MariaDB 和 MySQL 以不同的方式实现了并行刷新，但除非其中一种实现由于某种互斥锁争用而严重损坏，否则设置相同的线程数应该会产生可比较的性能，至少我在查看了两者之后是这样认为的。
就像 MariaDB/fusionIO 和 MySQL 页压缩实现之间也存在差异一样，但您仍然可以比较它们，不是吗？
是的，您是对的。这是我的错误。我不知道有这样一个参数，我不得不查看源代码以了解它们在方法上的相似性/差异。我需要使用修正后的配置重新运行页压缩的结果。对于未压缩和行压缩，这没有必要，因为这些结果即使在 MariaDB 上也没有使用多线程刷新。
我向这篇文章的读者道歉。显然，所有结果都不完全公平，尤其是页压缩的结果。我不知道 5.7 版本中有 innodb_page_cleaners 参数，在查看代码后，为了完全公平，在页压缩的运行中，我应该为该参数使用值 16。对于未压缩和行压缩，这没有必要，因为即使在 MariaDB 上也没有使用多线程刷新。
从评论中学到了很多。我期待看到更多关于 MariaDB 的基准测试。
很好的基准测试信息。在决定是否值得切换之前，我正努力寻找尽可能多的信息，以便将我的服务器升级到 MariaDB。只需要知道它能为 WordPress 带来多少性能提升。