小编Gia*_*awa的帖子

我在 AWS 上有一个托管的 MySQL (5.7.19) 实例。一般来说，事情运作得很好。我的 CPU 使用率始终保持在 4% 左右，远低于可突增实例 (t2.micro) 的 IOPS 限制。但是，如果我在可能已超出 RAM 且位于磁盘上的表上执行不使用索引的查询，则 MySQL 将“锁定”一分钟左右。读取 IOPS 确实会增加，但通常不足以进入我的信用池。CPU 将卡在 100% 直到查询完成。来自正常运行服务的其他连接将排队（我将开始看到 60 多个连接），并且许多连接最终会超时。

这是一个锁定数据库近一分钟的示例查询：

SELECT  *
    FROM  mydb.PurchaseDatabase
    WHERE  Time between '2018-11-20 00:00:00' AND '2018-11-23 00:00:00'
      and  ItemStatus=0
      and  ItemID="exampleitem";

这是我进行此查询时的 RDS 仪表板指标：

如果我第二次进行查询，它几乎立即完成（现在可能在 RAM 中来自最近针对同一个表的查询）。类似的查询也很快（例如 0.173 秒）。我启用了慢查询日志记录以及错误日志记录，并在一天后以相同的 30 秒延迟（表已被分页或 RAM 中的任何内容）进行查询。但是，没有任何内容写入慢查询表。我检查了错误日志，当我进行慢查询时，我可以看到这样的消息：

2018-11-28T06:21:05.498947Z 0 [注意] InnoDB: page_cleaner: 1000ms 预期循环用了 37072ms。设置可能不是最佳的。（在此期间，flushed=4 和 evicted=0。）

我认为这可能只是潜在问题的另一个症状，即我的实例在从磁盘读取/写入时遇到问题。我正在使用 SSD 支持的存储，我在 EBS 卷上的突发平衡不受这些慢查询的影响。在查询之前和之后，我有很多学分。

然后，我愚蠢地决定尝试通过清除旧记录来帮助数据库。我执行了这样的删除：

DELETE FROM mydb.PurchaseDatabase
    WHERE Time between '2018-01-01 00:00:00'
      and '2018-07-31 …