mysql性能基准

Posted 2023-03-06

【中文标题】mysql性能基准

【英文标题】：mysql performance benchmark

【发布时间】：2012-09-25 14:54:10

【问题描述】：

我正在考虑将我们的生产环境从自托管解决方案转移到亚马逊 AWS。我查看了不同的服务，并考虑使用RDS 作为我们的 mysql 实例的替代品。我们为 master 使用的硬件似乎比使用 rds（Quadruple Extra Large DB Instance）时所能获得的最好硬件要好。因为我不能简单地将我们的生产环境移动到 aws 并查看性能是否仍然足够好，所以我很想提前进行一些测试。

我考虑从我们当前的 master 创建一个完整的查询日志，配置 rds 实例并开始针对它重放完整的查询日志。实际上我什至不知道这种测试是否是一个好主意，但我想你会告诉我是否有更好的方法来确保在迁移到 rds 时 mysql 的性能不会急剧下降。

是否有首选工具来重放完整的查询日志？ 在运行测试时我应该查看哪些指标 cpu 使用率？ 内存使用情况？ 磁盘使用情况？ 查询时间？ 还有什么？

提前致谢

【参考方案1】：

我建议不要重播查询日志 - 几乎可以肯定它不会为您提供所需的信息，并且会花费大量精力。

首先，您需要准备好数据库，以便在插入、更新或删除数据时重放查询日志不会破坏约束，并且随后的“选择”查询将找到他们应该找到的记录。这在除了玩具数据库之外的任何东西上显然都不是微不足道的——仅仅备份并重放日志并不一定保证 DML 语句的顺序与生产中发生的顺序相匹配。这很可能会给您一种错误的舒适感 - 您的所有 select 语句都会在几毫秒内返回，因为它们要查找的数据不存在！

其次，负载和性能测试很少通过重播生产中发生的事情来进行 - 这并不能（通常）反映使您的系统崩溃的峰值条件。例如，大多数生产系统大部分时间都以

我的建议是使用像 JMeter 这样的工具来编写性能脚本（使用 JDBC 驱动程序直接写入数据库，或者如果您有 Web 应用程序，则通过前端）。您的性能脚本应该反映您从用户那里看到的行为，并进行参数化，以便它们不依赖于创建记录的顺序。

为自己设定一些绩效目标（最好基于当前的生产水平，并使用一个乘数来防止出现峰值），例如“100 个并发用户，查询时间不超过 1 秒”），并使用 JMeter 模拟该负载。如果你第一次到达，恭喜 - 回家！如果没有，请查看性能计数器以了解瓶颈在哪里；看看你是否可以缓解这个瓶颈（或者调整你的查询，你很棒的本地硬件可能隐藏了一些性能问题）。典型的瓶颈是 CPU、RAM 和磁盘 I/O。

用不同的测试场景进行实验 - “大量写入”、“大量读取”、“大量报告查询”，并将它们混合在一起。

这个想法是了解系统上的瓶颈，看看你离这些瓶颈有多远，并了解你可以做些什么来缓解它们。一旦您知道这一点，您迁移的决定就会更加稳健。

【讨论】：

我已接受您的回答，因为您给出的回答将是最好的选择。遗憾的是，如果您的应用程序有数百个用例，那么创建有效的测试套件并不容易。我刚刚发现 mysqlperformanceblog.com/2012/07/10/… 似乎非常适合这种情况。