我们有很长时间没有发布过在 Windows 下的基准测试文章了，而 Windows 下的 MariaDB 包含一些专门做的改进，这些改进很多人并不知晓，因为我们自己也很少提及。本文的目的是向你展示 MariaDB 在 Windows 下的性能表现。
进行测试的机器包含2个CPU共8核的处理器（这是我手头上能找到最好的机器了）、10K SAS 磁盘（RAID1），使用 sysbench 0.4 测试单表共100万行记录。我通过网络来运行这个压力测试，并发的客户端从 4 到 4096。
这里是 OLTP-只读 吞吐量测试结果：
说明：
绝大多数的测试结果表明，MariaDB 的吞吐量比 MySQL 高出 10% 左右 在 4096 并发客户端时，MariaDB 的吞吐量是 MySQL 5.5 的 四倍多 476% (2382 vs 413 TPS).很多人理所当然的认为吞吐量并不能代表数据库的整体性能表现。在 OLTP 的基准测试中，响应时间同样很重要，实际上它比吞吐量更加重要，这点我同意，因此，下面是查询的响应时间，意味着 95% 的事务都在指定的时间内处理完毕。
OLTP 只读响应时间 并发数 4 8 16 32 64 128 256 512 1024 2048 4096MariaDB 4.87 6.81 8.83 12.35 22.12 43.56 90.35 180.57 619.05 1003.88 1965.77
MySQL 4.86 7.14 9.96 16.21 37.39 101.33 238.89 499.63 971.07 2241.83 25215.29
上表中显示，MariaDB 5.5 不管是在吞吐量还是响应时间方面都是优于 MySQL 的。
但是，为什么 MariaDB 在 Windows 下的只读测试由于 MySQL 5.5 呢？二者基于同一个代码，表现应该也相同啊。这个问题的答案并不是 MariaDB 做了什么优化，也无关 XtraDB 和 InnoDB 的优劣。答案是 MariaDB threadpool. 这个线程池在 Windows 平台是默认启用的。
可是，为什么使用线程池就可以有如此好的性能呢？答案是 MariaDB 承担了通过调整线程池的大小并回调到对应的 Windows 本身的线程池，这在操作系统这一级别上相当于黑盒排序，因此能获取良好的性能。Windows 内置的线程池的核心，是自 NT 3.5 就有的技术，这是 Windows 专有的特性，运行在其上的服务器应该使用这种技术。要让这项技术运行良好的招数是：
不要让同一时间在同一个 CPU 上运行太多的线程，这样可减少上下文切换，这是提高吞吐量的最重要的因素 在完成的 LIFO 顺序中激活线程等待，热门的线程保持热门，可降低缓存失效 顺序处理 IO 完成，这是响应时间表现良好的因素 最后便是降低热锁的争用由此，线程池是只读性能表现佳的主要因素。
下一个有趣的问题是在写操作上 MariaDB 表现是否一致。因此我们使用写模式来运行 sysbench 工具，也就是 update_non_index (每个查询对一个非索引的整数字段进行加值处理)。为了最大化写的吞吐量，我们设置了参数 innodb_flush_log_at_trx_commit 值为 0，每次日志的写入是每秒一次，而不是每次事务提交一次。
测试结果如下：
OLTP write-only (update_non_index/flush_log=0) 吞吐量:
这个结果看起来很棒，差别来源于多个因素，包括 XtraDB 的写性能、分组提交、线程池等都对这个结果会有影响。但我想 Windows 平台下的 MariaDB 的 asynchronous IO optimization (异步 IO 优化) 是最主要的因素。
在上述测试中，所有 IO 相关的参数和 InnoDB 参数都使用的是默认值，结果看起来太好了以至于让我们怀疑这是真的。我真的想通过调整为 innodb_io_capacity and/or innodb_write_io_threads 参数为 MySQL 带来更加的性能，有人知道该如何调整吗？
OLTP writeonly (update_non_index/flush_log=0) 响应时间, 95 percentile 并发数 4 8 16 32 64 128 256 512 1024 2048MariaDB 0.33 0.63 0.75 1.06 1.94 3.85 8.25 21.38 129.79 274.40
MySQL 0.32 0.61 0.73 1.61 7.62 26.82 96.45 219.29 661.19 2723.36
下面是对数据库的参数调整：