PostgreSQL on RDS突发磁盘存储耗尽，异常查询致性能异常求助

结合你遇到的现象——某条查询直接导致PostgreSQL冻结、读写IOPS飙升，甚至把设备存储空间耗尽，删除查询后存储空间又恢复——最核心的原因大概率是失控的查询生成了大量临时文件，另外还有两种可能的场景也需要考虑：

1. 临时文件瞬间占满磁盘（最匹配你的情况） #

PostgreSQL在处理复杂查询时，比如对大表做ORDER BY、GROUP BY、哈希连接或者窗口函数计算，如果配置的work_mem内存不足以容纳中间计算结果，就会把数据写到磁盘上的临时文件里。如果你的查询存在以下问题，临时文件会疯狂膨胀：

• 没有加过滤条件的全表排序/聚合（比如直接对千万级大表执行SELECT * FROM large_table ORDER BY non_indexed_col;）
• 多表连接时漏写关联条件，意外产生笛卡尔积（比如SELECT * FROM table_a JOIN table_b;）
• 尝试导出超大结果集的查询（比如SELECT *拉取全表但中途卡住）

这些临时文件会在短时间内占满磁盘，导致数据库因为磁盘空间耗尽而冻结；同时持续读写这些大文件会直接拉满IOPS。当你终止这个查询后，PostgreSQL会自动清理这些临时文件，所以存储空间立刻恢复——这和你提供的前后存储变化完全对应。

2. 无索引的大范围读写引发WAL暴涨 #

如果这条查询是写操作（比如误执行了没有WHERE条件的UPDATE/DELETE，要修改全表数据），或者是反复执行的全表读查询，会触发两种问题：

• 读IOPS飙升：全表扫描会持续读取大量磁盘数据
• 写IOPS暴涨+存储空间耗尽：全表修改会生成巨量的WAL（预写日志）文件，这些文件会快速占满磁盘；同时未提交的大事务还会阻止VACUUM清理死元组，进一步占用空间。不过这种情况终止查询后，可能需要等待VACUUM或者WAL归档清理才能释放空间，和你“删除查询后立刻恢复”的情况略有区别，但也是需要排查的方向。

3. 长事务引发的数据库冻结与空间占用 #

如果这条查询属于一个长时间运行的事务，会导致PostgreSQL无法进行常规的VACUUM清理，死元组不断累积占用空间；同时长事务还可能触发数据库冻结（比如事务ID回绕风险引发的强制冻结）。不过这种情况的空间占用是渐进式的，不会突然耗尽，所以可能性相对较低。

后续排查建议 #

• 查看PostgreSQL的日志文件，定位到那条失控的查询语句，检查是否存在上述的逻辑问题
• 检查work_mem、maintenance_work_mem等内存参数的配置，是否因为过小导致频繁生成临时文件
• 对查询涉及的大表添加合适的索引，避免不必要的全表扫描

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