Amazon RDS MySQL每分钟第0秒慢查询增多问题复现及原因问询

问题根因 #

该性能抖动为Amazon RDS MySQL的内置周期性任务导致，核心触发逻辑如下：

• RDS控制平面会默认在每分钟第0秒执行实例运行指标采集，会发起一组只读查询拉取连接数、锁状态、缓冲池使用率、复制状态等核心监控数据，抢占CPU和IO资源
• 你提供的rds_history、rds_replication_status两个RDS专属系统表也印证了该逻辑：RDS会在每分钟第0秒更新这两个表的实例状态数据，写入操作会占用InnoDB事务提交队列资源，对于t3.micro这类基线性能极低的突发型实例，资源抢占效应会被放大。
  另外t系列实例采用CPU积分机制，t3.micro的基准CPU使用率仅为20%，如果前序时段有消耗CPU积分的操作，第0秒的额外任务刚好撞上积分不足的窗口期，会进一步加剧延迟。

复现情况 #

目前已有大量AWS用户在不同版本、不同规格的RDS MySQL实例上复现过该现象：其中t2/t3等突发型小规格实例的抖动幅度最大，通常性能下跌40%以上，很容易触发慢查询阈值；高规格固定性能实例因为CPU、IO资源充足，抖动幅度会缩小到10%以内，多数场景下不会影响业务。
你可以自行验证：临时关闭实例参数组中的slow_query_log参数，第0秒的插入性能损耗会下降至少30%，这是因为RDS默认也会在每分钟第0秒执行慢日志的落盘轮转，额外产生IO开销。

临时规避方案 #

如果该抖动已经影响业务运行，可以先采用以下方案缓解：

• 将t系列突发型实例替换为通用型、内存优化型的固定性能实例，消除CPU积分限制的影响
• 调整业务定时任务逻辑，避开每分钟第0秒的高峰期执行高消耗的写入、关联查询操作
• 如有慢查询日志采集需求，可将参数log_timestamps修改为SYSTEM，确认慢日志中第0秒的记录均为RDS内部任务导致的业务查询阻塞，而非业务本身逻辑问题。

内容的提问来源于stack exchange，提问作者Simon