我正在考虑将我们的生产环境从自托管解决方案转移到亚马逊 AWS。我查看了不同的服务，并考虑使用RDS替代我们的 mysql 实例。我们为 master 使用的硬件似乎比使用 rds（Quadruple Extra Large DB Instance）时所能获得的最好硬件要好。因为我不能简单地将我们的生产环境移动到 aws 并查看性能是否仍然足够好，所以我很想提前进行一些测试。
我考虑从我们当前的 master 创建一个完整的查询日志，配置 rds 实例并开始针对它重播完整的查询日志。实际上我什至不知道这种测试是否是一个好主意，但我想你会告诉我是否有更好的方法来确保在迁移到 rds 时 mysql 的性能不会急剧下降。
提前致谢
我建议不要重播查询日志——它几乎肯定不会给你想要的信息，而且会花费大量的精力。
首先，您需要准备好数据库，以便在插入、更新或删除数据时重放查询日志不会破坏约束，并且后续的“选择”查询将找到他们应该找到的记录。这在除了玩具数据库之外的任何东西上显然都不是微不足道的——仅仅备份并重放日志并不一定保证 DML 语句的顺序与生产中发生的顺序相匹配。这很可能会给您一种错误的舒适感——您的所有选择语句都会在几毫秒内返回，因为它们要查找的数据不存在！
其次，负载和性能测试很少通过重播生产中发生的事情来进行——这（通常）不能反映使您的系统崩溃的峰值条件。例如，大多数生产系统大部分时间都以 <50% 的容量愉快地运行，但在白天会经历峰值，当它们可能达到 80% 或更多的容量时——这就是你关心的，你的新环境能否处理峰值.
我的建议是使用JMeter之类的工具来编写性能脚本（使用 JDBC 驱动程序直接写入数据库，或者如果您有 Web 应用程序，则通过前端）。您的性能脚本应该反映您从用户那里看到的行为，并进行参数化，以便它们不依赖于创建记录的顺序。
为自己设置一些性能目标（最好基于当前的生产水平，用一个乘数来保护您免受峰值影响），例如“100 个并发用户，没有超过 1 秒的查询”），并使用 JMeter 来模拟该负载。如果你第一次到达，恭喜 - 回家！如果没有，请查看性能计数器以了解瓶颈在哪里；看看你是否可以缓解这个瓶颈（或者调整你的查询，你很棒的本地硬件可能隐藏了一些性能问题）。典型的瓶颈是 CPU、RAM 和磁盘 I/O。
尝试不同的测试场景——“大量写入”、“大量读取”、“大量报告查询”，并将它们混合起来。
这个想法是了解系统上的瓶颈，看看你离这些瓶颈有多远，并了解你可以做些什么来缓解它们。一旦您知道这一点，您迁移的决定就会更加稳健。