RDS 磁盘空间不足排查实战：从空间统计到日志清理的五步流程

背景

某天凌晨，华为云 RDS for MySQL 实例触发磁盘使用率超过 85% 的告警，随后写入开始变慢，继续上涨有进入只读状态的风险。本文记录一次真实的排查过程：先用控制台和 SQL 把空间构成统计清楚，再按表空间、日志、长事务的顺序定位占用大户，最后用安全的方式清理日志并做长效治理。全程只通过控制台和 SQL 操作，不需要登录数据库服务器文件系统。

第一步：确认告警与空间分布

1. 在 RDS 控制台打开实例详情，进入监控页，确认磁盘使用率曲线是缓慢爬升还是突发上涨，缓慢爬升多为数据或日志自然增长，突发上涨要优先怀疑大事务、批量导入或日志暴涨。
2. 用客户端登录实例，查看当前 binlog 文件列表和过期参数，先拿到日志部分的粗略规模。

mysql -h <实例地址> -P 3306 -u <账号> -p -e "SHOW BINARY LOGS;"
mysql -h <实例地址> -P 3306 -u <账号> -p -e "SHOW VARIABLES LIKE 'binlog_expire_logs_seconds';"

3. 把磁盘占用拆成三类来记：数据文件、binlog 与慢日志等日志文件、临时文件与回滚段。先分类再动手，避免在错误的方向上清理。

第二步：统计表空间，定位大表

1. 查询 information_schema.TABLES，按数据加索引的总大小排序，取前 20 张表，先看是单表过大还是多张表共同变大。
2. 同时关注 data_free 字段，碎片大的表做完批量删除后空间并不会自动归还给磁盘。

SELECT table_schema AS '数据库',
       table_name AS '表名',
       ROUND((data_length + index_length) / 1024 / 1024, 2) AS total_mb,
       ROUND(data_free / 1024 / 1024, 2) AS free_mb
FROM information_schema.TABLES
ORDER BY total_mb DESC
LIMIT 20;

3. 如果是大表导致空间不足，优先做业务侧的判断：能否归档冷数据、能否按时间分表、能否把不再查询的历史数据迁移到对象存储或归档库。不要一上来就删生产数据。

第三步：统计日志空间，定位 binlog 与慢日志

1. 把 SHOW BINARY LOGS 返回的 File_size 列加总，就是 binlog 的总占用；文件数量突然增多，通常对应写入量突增或过期清理失效。
2. 检查慢查询日志和错误日志是否开启、保留多久，再检查是否有长时间运行的事务拖住 undo 回滚段。

SELECT trx_id, trx_started,
       TIMESTAMPDIFF(SECOND, trx_started, NOW()) AS running_seconds
FROM information_schema.innodb_trx
ORDER BY trx_started;

3. 如果发现运行几小时的事务，先确认它是否还在做有效写入。长事务不结束，undo 空间不会回收，贸然杀事务也要先评估业务影响。

第四步：安全清理日志，回收碎片空间

1. 清理 binlog 之前必须确认两件事：从库是否已经消费到目标位置，是否还需要这些 binlog 做按时间点恢复。清理掉从库还没读到的 binlog，会导致主从复制中断。
2. 在从库上确认复制位置后，再在主库上清理到指定文件，保留该文件及之后的文件。

-- 在从库上确认复制位置
SHOW SLAVE STATUS\G
-- 在主库上清理到指定文件，保留该文件及之后的文件
PURGE BINARY LOGS TO 'mysql-bin.000124';

3. 更推荐的做法是改自动过期策略：在控制台参数修改中把 binlog_expire_logs_seconds 从默认的 7 天调到 3 天，让系统自动滚动清理，避免反复手动清理。
4. 碎片大的表，在低峰期用 OPTIMIZE TABLE 或重建表回收空间，执行期间会产生锁表和 IO，务必避开业务高峰。

第五步：扩容与长效治理

1. 清理完成后如果磁盘使用率仍然高于 80%，直接在控制台做在线磁盘扩容，不需要停机，扩容是兜底手段，不是替代治理。
2. 把磁盘使用率、binlog 数量、长事务时长三项指标接入告警，阈值分别设为 75% 预警和 85% 严重，避免下次等到快满才发现。
3. 建立月度例行动作：归档超过保留期的历史数据、复查慢日志中反复出现的大查询、复查 binlog 过期参数是否被其他变更改回默认值。

小结

这次排查的结论很清晰：先统计再清理，先分类再动手。磁盘空间不足很少是单一原因，多数是数据增长、binlog 保留过长和个别大表三件事叠加。按五步流程走——确认分布、定位大表、统计日志、安全清理、扩容治理——可以在不丢数据、不中断复制的前提下把空间降回来。最关键的两条红线是：不要清理从库未消费的 binlog，不要直接删除数据库服务器上的文件，RDS 是托管服务，日志清理要走 SQL 和控制台。