MariaDB-5.3 优化器基准测试

当我发布 MariaDB-5.3.4 sysbench 结果 时，我说过“如果您的工作负载包含复杂的（子）查询，那么您可能会从 MariaDB 的新优化器功能中获益更多”。今天我将介绍一些复杂工作负载的基准测试结果。

本次基准测试是 DBT3，它是 TPC-H 规范的一个实现。DBT3 用 C 语言编写，并托管在 Sourceforge 上。

DBT3 基准测试可以在不同的扩展因子下运行——这决定了数据库的大小。我使用了扩展因子 30，产生了约 30GB 的原始数据和约 48GB 的磁盘占用空间。运行基准测试的机器有 16GB 内存。

InnoDB 存在表统计信息波动的问题，这导致查询计划相当不可预测。因此，基准测试表是使用 MyISAM 引擎创建的。我将来肯定会针对 InnoDB 运行此基准测试，但这需要在我们的 DBT3 自动化脚本中进行一些修改。

MySQL 和 MariaDB 都需要调整以使用新的优化器功能。具体来说，我开启了multi-range-read 和 batched-key-access。MRR 成本估算功能被关闭了，因为它在 MySQL-5.6 和 MariaDB 中都未准备好用于生产环境。详情请参阅包含配置文件的tarball 文件。

以下重点关注 DBT3 的Power Test，它包含 22 个相当重的 JOIN 查询。每个查询在冷缓存（服务器重启 + 文件系统缓存清除）上运行了 5 次。查询执行时间限制为 2 小时超时。执行时间在 10 秒到 >2000 秒之间变化，因此在下图中，执行时间被归一化处理（MariaDB = 100%）。彩色条显示中位数，须线显示最小值和最大值

从这里我们可以看到 MySQL-5.5 难以很好地应对这种类型的工作负载。MySQL-5.6 在许多查询上有所改进，但在查询 3 或 8 上甚至比 5.5 更差。比较神秘的是查询 22，其中 MySQL 5.5 位居第一。

欲了解更多详情，这里有一张包含数据的表格。我已将获胜者的行（与图表颜色相同）进行了着色。如果差异低于 5%，则视为平局，这些行未着色。

查询 11 是平局，因为差异只有 1 秒（时间测量的粒度）。查询 11 在 MariaDB 上表现出一种奇怪的现象：第一次运行耗时 43 秒，随后的运行仅需 13 秒。这可能是磁盘控制器的缓存效应。

两个 MySQL 版本都没有在时限内完成查询 18。这 3 个参测版本都没有在时限内完成查询 20。

查询执行计划在参测版本之间有所不同。有时我可以通过强制使用已知的良好连接顺序（使用 straight_join）来微调结果。例如，在查询 7 上，MariaDB 使用了不同的连接顺序。当我强制使用 MySQL 的计划时，MariaDB 仅需要 MySQL 时间的约 70%。或者对于查询 12，MySQL 5.5 使用的计划与其他版本不同。在强制使用更好的连接顺序后，所有 3 个版本在相同的时间内完成。

最后，我还有另一张图表，这次显示的是 100% 区域附近的详细信息。

如果您想自己运行 DBT3 基准测试，可以使用我们的 DBT3 脚本。我将这些脚本的配置文件和提取的原始数据打包成 tarball，可在此下载。