过去几天，我们的 IOP 已经达到上限。我们多次调配了更多的 IOPS。1250 -> 2500 -> 4500。每一步我们都很快发现，我们正在使用所有可用的 IOPS，因为它会在读取和写入之间达到最大值。
今天早上，我们终于迎来了另一位大客户，我们的 CPU、内存和 IOPS 都达到了极限。我决定提供更大的数据库类型以保持系统运行。我们从 db.m5.xlarge 升级到了 db.m5.2xlarge。我们还通过升级将 IOP 提升到了 8000。
现在我们的 CPU 相比之下受到了重击，我们的 IOPS 实际上为 0。该应用程序似乎响应迅速，但我们的任务队列相当慢。
代码没有改变，只有数据库。我遗漏了什么？RDS 报告不正确吗？
您会注意到过去 3 天内读取 IOPS 的跳跃，这与更高的 IOPS 规定相一致。
答案1
您可能有一个查询失败了。（感谢您的详细描述。以下是可能的解释。）
举个例子。假设一个查询正在扫描一个 7GB 的表（没有有用的索引等），其中包含 70M 行。
情况 1：RAM = 8GB；innodb_buffer_pool_size= 6GB。查询会将所有内容从缓存中移出以完成扫描。这需要稳定的 I/O。所有其他查询也会受到影响 - 它们的数据也会从 RAM 中移出。
情况 2：RAM = 16GB；innodb_buffer_pool_size= 12GB。第一次扫描将整个表加载到缓存中；该查询的后续运行不需要执行任何 I/O。由于缓存没有争用，其他查询的运行速度也更快。
在这两种情况下，查看所有 7000 万行都可能需要消耗大量的 CPU。
计划 A：花钱购买更多的 RAM、CPU 和不需要的 IOP。
计划 B：找到那个非常棘手的查询，然后让我们帮您优化它。然后您就可以回到更便宜的 VM 了。
请提供查询和SHOW CREATE TABLE所涉及的表。解决方案可能很简单，只需添加复合索引或重新制定查询即可。
答案2
这里的关键是根本不做任何事情。“神奇的是”我们的 CPU 恢复到了我预期的水平。好消息是，我发现了我们的查询中的几个痛点、一些过度的锁定以及对调整 InnoDB/RDS/MySQL 的大量理解。
也许 RDS 正在缓慢地优化索引或其他我不完全理解的事情，但现在我们的延迟是惊人的，吞吐量和使用率完全达到了我预期，增加了 4 个内核和 2 倍内存。
