在许多服务器运维场景中，MySQL 占用硬盘空间异常增大的问题几乎人人都经历过。数据库运行一段时间后，磁盘却突然被写满，导致网站无法写入、服务异常、甚至数据库直接崩溃。造成这一问题的原因往往不是单一因素，而是 binlog、错误日志、慢日志、临时文件、碎片化数据以及冗余的历史数据共同累积的结果。因此，要彻底解决 MySQL 占用硬盘过大的问题，需要进行结构化的排查、定位与清理。同时，必须确保清理过程安全可控，避免误删导致数据库损坏。
在实际处理 MySQL 占用空间问题之前，需要先确认当前磁盘空间情况，以便判断是否为数据库导致的占满。可以通过以下命令查看磁盘使用情况：
df -h如果发现 /var/lib/mysql 或挂载 MySQL 数据目录的分区使用率接近 100%，就说明 MySQL 极有可能是罪魁祸首。随后需进一步查看 MySQL 数据目录的占用结构：
du -sh /var/lib/mysql/*该命令可以快速找出究竟是哪个库或哪个文件占用了大量空间。通常大文件包括 ibdata1、ib_logfile0/1、binlog 文件、error log 和 .ibd 表文件等。确认占用来源后，便可进行针对性排查。
在 MySQL 占用空间突然异常增大的案例中，binlog(Binary Log)膨胀是最常见的原因之一。开启 binlog 后，MySQL 会记录所有变化性操作，如果不设置删除策略，文件会无限累积。在数据写入量较大的场景，比如电商、采集系统、高频写入业务，binlog 会在短时间内增长到数十甚至数百 GB。要检查 binlog 文件大小，可以执行：
ls -lh /var/lib/mysql/binlog.*如果数量巨大，则需要检查当前 MySQL 的过期策略：
show variables like 'expire_logs_days';
show variables like 'binlog_expire_logs_seconds';
如果这两个值均为 0，则表示 binlog 永不过期，需要立即设置过期策略：
set global expire_logs_days = 7;或者基于秒级配置：
set global binlog_expire_logs_seconds = 604800;也可以手动清理：
purge binary logs before date_sub(now(), interval 7 day);但需要确保主从同步正常，否则可能导致复制中断。
另一个造成磁盘占用巨大的因素是 MySQL 日志文件，包括 error log、slow query log、general log。在高并发系统中，如果开启了详细日志，却没有定期轮转，会导致错误日志动辄几十 GB。特别是在服务器出现某些特定错误时，比如重复报错、连接失败、磁盘问题，log 会在短时间内疯狂增长。检查日志文件大小：
ls -lh /var/log/mysql/或：
ls -lh /var/lib/mysql/*.log如果 slowlog 或 error.log 在不断暴涨，需要立即停止写入日志：
set global slow_query_log = 0;然后轮转日志：
mv /var/log/mysql/error.log /var/log/mysql/error.log.bak
systemctl restart mysql随后应查明日志暴涨的根本原因，例如索引缺失导致慢查询过多，或某些业务脚本异常导致连接失败。
在 InnoDB 存储引擎中，ibdata1 文件常常是磁盘最大占用者，它包含表元数据、回滚段、事务日志等内容。然而 InnoDB 的空间回收不支持自动 shrink，即使删除了大量数据，ibdata1 仍不会缩小。而当频繁进行大批量写入 / 删除时，ibdata1 可能迅速膨胀。查看 ibdata 文件大小：
ls -lh /var/lib/mysql/ibdata1如果其大小达到数十 GB，说明 InnoDB 膨胀严重。要清理 ibdata1，需要进行彻底重构，操作复杂且风险高，因此作为最后的方案。
某些情况下，MySQL 的临时表文件也会占用大量磁盘。执行复杂查询时，特别是 ORDER BY、GROUP BY、JOIN 或大批量排序操作，如果 RAM 不足，MySQL 会将临时表写入磁盘。临时文件位置通常是 /tmp 或 MySQL 配置的 tmpdir。检查临时文件：
ls -lh /tmp/如果看到大量以 #sql 开头的文件，并持续增长，说明 SQL 查询设计不合理，或 innodb_buffer_pool 太小。清理之前必须确认文件未被 MySQL 使用。可以尝试重启：
systemctl restart mysql重启会清除临时文件，但根本解决方案是优化 SQL 或加大内存配置。
随着业务运行时间延长，许多表的 .ibd 文件会逐渐膨胀，这既可能是存储大量历史数据导致，也可能是碎片化造成。检查某个库的表文件大小：
du -sh /var/lib/mysql/dbname/*如果发现某些表特别大，而业务实际数据量没有那么多，可以执行 OPTIMIZE TABLE 回收碎片：
optimize table table_name;但需注意，该操作会锁表，业务繁忙时请谨慎使用。
在排查完成并清理大文件后，还需要确保 MySQL 的未来运行不会再次造成磁盘暴增。因此，应建立合理的自动化管理机制。例如定期清理 binlog：
expire_logs_days = 7定期轮转 error log：
log_error_verbosity = 2优化内存配置减少临时文件落盘：
innodb_buffer_pool_size = 4G
tmp_table_size = 512M
max_heap_table_size = 512M并定期监控磁盘占用：
du -sh /var/lib/mysql/对于大规模数据库，应使用监控系统如 Prometheus + mysqld_exporter 或 Zabbix，实时跟踪数据目录增长情况，确保能提前发现异常。
在清理过程中，最关键的原则是：任何涉及删除文件的操作都必须先备份。很多新手误删除 binlog 或 ibdata，导致数据库无法启动。为避免风险，务必遵循 “先备份、再清理、后验证” 的流程。
整体而言，MySQL 占用硬盘空间过大往往是多因素叠加造成的，并不是简单删除文件就能解决。必须结合 binlog、日志文件、InnoDB 表空间、临时文件、表碎片等多个方面进行全面排查，通过科学的调优与定期维护，才能从根本上避免数据库膨胀问题，保障业务持续稳定运行。
