AWS RDS已分配存储量过高原因排查及存储内容查询

可能的触发原因 #

• 临时文件/事务日志堆积：数据库运行时的排序、哈希操作会生成临时表，未及时提交的大事务会导致undo日志（MySQL）膨胀；PostgreSQL的WAL日志如果备份/副本同步延迟，也会大量占用存储。这些文件不属于数据库逻辑大小，所以查询数据库大小看不到。
• 存储引擎未释放空间：比如MySQL InnoDB删除数据后，释放的空间只会标记为引擎内部可复用，不会还给操作系统，长期积累会占用实例存储；PostgreSQL的死元组未清理也会导致空间占用。
• 突发写入触发自动扩容：短时间内的批量导入、临时数据写入可能触发RDS自动扩容，之后数据被删除，但RDS不支持自动缩容，已分配的存储会保留下来。
• 只读副本同步异常：如果有只读副本，主实例的binlog（MySQL）或WAL（PostgreSQL）未被副本及时拉取，会导致主实例上的日志文件持续堆积。
• 系统日志/临时备份文件占用：RDS实例的操作系统层面可能有系统日志、数据库错误日志等文件占用空间，这些不在数据库逻辑大小统计范围内。

查看已分配存储内容的操作方法 #

针对MySQL引擎 #

1. 检查InnoDB空间明细
   执行以下SQL查看各数据库的数据、索引大小，以及引擎未释放的空间：

   SELECT 
     table_schema AS '数据库名',
     pg_size_pretty(SUM(data_length)) AS '数据大小',
     pg_size_pretty(SUM(index_length)) AS '索引大小',
     pg_size_pretty(SUM(data_free)) AS '引擎未释放空间'
   FROM information_schema.tables 
   GROUP BY table_schema;
   

   引擎未释放空间就是InnoDB占着但没还给操作系统的部分，这会算在RDS已分配存储里。

2. 检查binlog日志状态
   查看binlog的数量和大小，判断是否因副本同步问题导致日志堆积：

   SHOW BINARY LOGS;
   

   同时可以检查binlog保留时长参数expire_logs_days，如果设置过大也会导致日志堆积。

3. 排查长事务
   未提交的长事务会拖慢undo日志清理，执行：

   SHOW ENGINE INNODB STATUS;
   

   在输出中查找TRANSACTIONS部分，查看是否有长时间运行的事务。

针对PostgreSQL引擎 #

1. 检查数据库空间使用
   查看各数据库的实际大小、未释放空间：

   SELECT 
     datname AS '数据库名',
     pg_size_pretty(pg_database_size(datname)) AS '数据库总大小',
     pg_size_pretty(pg_total_relation_size(quote_ident(datname))) AS '数据+索引大小',
     pg_size_pretty(pg_database_size(datname) - pg_total_relation_size(quote_ident(datname))) AS '未释放空间'
   FROM pg_database;
   

   再检查表的死元组情况：

   SELECT 
     schemaname, tablename, 
     pg_size_pretty(pg_relation_size(quote_ident(tablename))) AS '表大小',
     pg_size_pretty(pg_stat_get_dead_tuples(quote_ident(tablename))) AS '死元组大小'
   FROM pg_tables WHERE schemaname = 'public';
   

2. 检查WAL日志堆积
   查看WAL日志总大小：

   -- PostgreSQL 9.x
   SELECT pg_size_pretty(pg_xlog_location_diff(pg_current_xlog_location(), '0/0')) AS 'WAL总大小';
   -- PostgreSQL 10+
   SELECT pg_size_pretty(pg_wal_location_diff(pg_current_wal_lsn(), '0/0')) AS 'WAL总大小';
   

   如果数值过大，说明归档或副本同步有问题。

RDS控制台层面排查 #

• 进入实例的监控页面，查看已分配存储、可用存储空间、存储使用量的变化趋势，确认扩容是突发还是缓慢增长，对应时间点排查数据库操作。
• 查看事件历史，找到第一次触发自动扩容的时间，结合当时的业务操作分析原因。
• 检查只读副本的同步状态，如果副本延迟过高或处于异常状态，会导致主实例日志无法清理。

解决建议 #

• 针对引擎未释放空间：低峰期对碎片化严重的表执行OPTIMIZE TABLE（MySQL）或VACUUM FULL（PostgreSQL），重建表释放空间。
• 针对日志堆积：修复只读副本的同步问题，调整binlog/WAL的保留时长，清理过期日志。
• 针对长事务：找到并终止长时间未提交的事务，规范业务操作避免长事务。
• 手动缩容：确认存储确实有大量闲置后，在低峰期手动修改RDS实例的存储大小（比如设为200GB），多数引擎支持无停机调整。

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