先运行 df -h 和 df -i 确认空间与 inode 是否耗尽，重点检查 /var/lib/mysql、/tmp 和日志路径；再按优先级排查 binlog、general_log、slow_query_log 等日志膨胀问题，并结合 sql 查询大表、碎片及临时文件定位根因。
数据库数据文件暴增是磁盘告警的常见根因，尤其在 MySQL、PostgreSQL 或 MongoDB 等服务未配置自动清理、归档或空间限制时。排查不能只盯着“日志”，而要直击数据目录本身——因为真正吃掉几十GB甚至上百GB空间的，往往是表文件（.ibd、.dat、.wal）、WAL 日志、事务日志或未清理的备份快照。
确认是否真由数据库文件导致
先排除干扰项，避免误判：
- 执行
df -h和df -i，确认是空间满（非 inode 满）；重点看数据库数据目录所在挂载点，比如/var/lib/mysql、/var/lib/postgresql、/data/mongodb所在分区是否已接近 100%； - 用
du -sh /var/lib/mysql/* 2>/dev/null | sort -hr | head -5快速查看 MySQL 下哪些库或系统目录最大； - 对比
df -h显示的已用空间与du -sh /var/lib/mysql总和：若差值显著（如 df 显示用了 80G，du 只统计出 40G），说明存在被进程占用但已删除的文件（如旧 binlog、未关闭的临时表文件），需查lsof +L1；
定位具体膨胀的数据库对象
进入数据库服务内部，比单纯看文件更精准：
Browser Setup (No-Root Linux)
下载
在无 root/sudo 权限的环境（云容器、VPS、隔离主机）中安装并配置 OpenClaw 浏览器工具的 headless Chrome。适用场景：...
-
MySQL：登录后执行：
SELECT table_schema, table_name, round(((data_length + index_length) / 1024 / 1024), 2) AS size_mb FROM information_schema.TABLES ORDER BY size_mb DESC LIMIT 10;
关注information_schema、mysql系统库中异常大的表（如general_log、slow_log若开启且未轮转）； -
PostgreSQL：连接后运行：
SELECT pg_size_pretty(pg_total_relation_size(quote_ident(schemaname) || '.' || quote_ident(tablename))) AS size, schemaname, tablename FROM pg_tables ORDER BY pg_total_relation_size(quote_ident(schemaname) || '.' || quote_ident(tablename)) DESC LIMIT 10;
同时检查pg_wal/目录大小（du -sh /var/lib/postgresql/*/main/pg_wal），WAL 积压常因备库延迟或归档失败导致； -
MongoDB：用
mongosh连接后执行：db.adminCommand({listDatabases: 1}).databases.forEach(db => print(`${db.name}: ${Math.round(db.sizeOnDisk/1024/1024)} MB`));
再进具体库查大集合：db.getCollectionNames().forEach(c => print(c + ': ' + db[c].stats().size));
检查数据库自身的增长源
数据暴增往往不是“自然增长”，而是配置或行为异常：
-
日志类文件失控：MySQL 的
binlog、general_log、slow_query_log；PostgreSQL 的pg_log和 WAL；MongoDB 的mongod.log。检查配置中是否启用了但未设置轮转（如 MySQLexpire_logs_days为 0 或未设）； -
未清理的历史数据：业务表无定期归档或
DELETE + OPTIMIZE，尤其是带大文本字段（TEXT、BLOB）的表，删除后空间不自动回收（InnoDB 需OPTIMIZE TABLE或启用innodb_file_per_table并重建）； -
临时文件残留：大查询生成的
tmp_table存在/tmp或datadir/tmp；或 mysqldump、pg_dump 过程中断，留下巨型临时 SQL 文件； -
备份文件滞留：手动
mysqldump、pg_basebackup或 mongodump 输出未及时移出数据目录，甚至直接 dump 到/var/lib/mysql/backup.sql—— 这类文件既占空间又极难被常规 du 发现（因路径太深或权限受限）。
安全清理与后续防护
清理前务必确认影响范围，优先选低风险操作：
- 清空日志类文件：用
echo > /var/lib/mysql/mysql-bin.000001（需确保已关闭log_bin或主从同步已完成）；或 MySQL 中执行PURGE BINARY LOGS BEFORE '2026-09-20 00:00:00';； - 清理旧备份：确认备份已上传至对象存储或异地后，再
rm -f /var/lib/mysql/*.sql /var/lib/mysql/backup_*.tar.gz； - 收缩大表空间：MySQL 中对单表执行
OPTIMIZE TABLE huge_table;（注意锁表）；PostgreSQL 中用VACUUM FULL（慎用，阻塞读写）或pg_repack； - 加防护：立即配置日志自动轮转（MySQL
expire_logs_days=7）、设置 WAL 归档超时（PostgreSQLarchive_timeout = 3600）、监控pg_wal目录大小、为 MongoDB 启用systemLog.logRotate: rename。
