MySQL 安装完成后，磁盘空间迅速被占满？这是许多数据库管理员和运维工程师在部署MySQL时遇到的典型问题，尤其在使用了某些集成安装包或特定Docker镜像后。无需立即考虑磁盘扩容，问题的根源很可能出在日志配置上。
通用查询日志（general_log）持续写入会迅速耗尽磁盘
MySQL默认并未开启general_log功能。然而，部分预配置环境或自动化运维脚本为了调试方便，可能会默认启用此功能。更关键的是，其日志文件通常默认存放在/var/lib/mysql/目录下，该目录往往与核心数据文件共享同一磁盘分区。
一旦此功能被激活，所有数据库操作都将被完整记录。从客户端连接到断开，从数据库切换到每一条SQL语句的执行，无论查询多么简单，都会被实时追加写入日志文件。这种不间断的写入行为，在短时间内即可产生数十GB的日志文件，直接导致磁盘空间告急。
如何快速诊断问题？执行以下SQL命令即可：
SHOW VARIABLES LIKE 'general_log%';
若查询结果显示general_log状态为ON，且general_log_file路径指向/var/lib/mysql/xxx.log，那么基本可以确定它就是导致磁盘空间爆满的元凶。
接下来，按照以下步骤进行紧急处理与永久修复：
- 立即停止写入：执行
SET GLOBAL general_log = OFF;临时关闭通用查询日志。请注意，此命令可能仅对新会话生效，已存在的连接可能仍会短暂写入。 - 确认文件句柄：运行
lsof -n | grep mysql.*log检查日志文件是否仍被mysqld进程占用。若存在占用，使用kill -9终止对应进程可确保写入完全停止。 - 安全清理日志：此处需特别注意——直接使用
rm -f命令删除日志文件可能无法立即释放磁盘空间。如果mysqld进程仍持有该文件的句柄，删除操作仅会移除目录项，而磁盘空间不会被回收（表现为df显示空间已满，但du却找不到大文件）。更安全的做法是清空文件内容：echo '' > /var/lib/mysql/general.log。 - 永久关闭配置：在MySQL配置文件
my.cnf（或my.ini）的[mysqld]段落下，添加general_log = 0配置项，随后重启MySQL服务，以确保该功能被彻底禁用。
注意区分：清理二进制日志无法解决通用查询日志问题
许多用户在遇到磁盘空间不足时，会首先尝试清理二进制日志（binlog），例如执行PURGE BINARY LOGS命令。但此操作对general_log无效。二进制日志与通用查询日志是两种功能完全不同的日志：前者用于主从复制和基于时间点的数据恢复，后者则用于审计所有查询行为。它们的启用变量、存储路径和管理方式均不相同，切勿混淆。
检查通用日志后，勿忘慢查询日志（slow_query_log）
通用查询日志问题较为明显，但其“兄弟”——慢查询日志同样不容忽视。虽然默认关闭，但若曾被开启且长期未维护，经年累月也可能积累数GB的磁盘空间。
检查方法类似：SHOW VARIABLES LIKE 'slow_query_log%';。处理流程也相同：临时关闭、清空文件、在配置文件中永久禁用或合理设置slow_query_log参数。
真正复杂的磁盘空间问题，通常源于ibdata1系统表空间文件的异常膨胀，或二进制日志文件的无序堆积。但这类问题多见于数据库长期运行后，属于“慢性病”。而“安装后立即爆盘”的现象，绝大多数情况下是由日志配置不当引发的“急性病”。因此，遇到此类情况，首先重点排查general_log和slow_query_log的配置状态，往往能快速定位并解决问题。
