SELECT查询是否会导致高写入IOPS？AWS RDS MySQL异常排查

你的推测完全正确——这类聚合查询确实会因为临时表超出内存限制而触发磁盘写入，进而占用大量写入IOPS，导致AWS RDS MySQL实例卡顿。

触发磁盘写入的核心原因 #

MySQL执行GROUP BY、DISTINCT这类聚合操作时，会先创建临时表存储分组的中间结果：

• 默认优先使用内存临时表（MEMORY引擎），但受限于tmp_table_size和max_heap_table_size两个参数的最小值（默认通常仅几十MB）。
• 当聚合生成的中间结果（比如百万行数据分组后得到的十万行数据）超过这个阈值时，MySQL会自动将内存临时表转换为磁盘临时表（通常为InnoDB引擎），这一过程会产生大量磁盘写入，直接拉高写入IOPS和延迟。

验证方法 #

• 检查慢查询日志：找到耗时久的聚合查询，日志中带有Using temporary标记说明使用了临时表；若同时出现Using filesort，基本可以确认触发了磁盘写入。
• 执行状态查询：运行SHOW GLOBAL STATUS LIKE 'Created_tmp_disk_tables';，如果该数值持续快速增长，说明存在大量临时表刷盘的情况。
• 关联RDS监控：对比CloudWatch中WriteIOPS、WriteLatency飙升的时间段，和慢查询日志中聚合查询的执行时间是否匹配。

优化方案 #

• 调整临时表参数：在RDS参数组中适当调高tmp_table_size和max_heap_table_size（注意不要超过实例可用内存，避免内存溢出），比如设置为2GB（根据实例规格调整），降低临时表刷盘的概率。
• 优化聚合查询：
  给分组字段、过滤字段创建合适的联合索引，让MySQL可以通过索引直接完成分组，避免全表扫描和临时表生成。
  通过WHERE子句过滤掉无关数据，减少需要聚合的行数，缩小临时表的规模。
• 拆分大查询：将单次生成十万行结果的聚合查询拆分为多个小范围查询，在应用层合并结果，避免一次性生成过大的临时表。
• 升级实例存储：如果磁盘IO是瓶颈，可切换到gp3存储类型并自定义更高的IOPS配额，或升级到IO优化型实例，提升磁盘写入能力。

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