通用查询日志（general_log）开启会导致每条SQL被持续追加写入磁盘，几小时即可撑爆几十GB；应立即执行SET GLOBAL general_log = OFF关闭，再清空日志文件内容（如echo '' > /var/lib/mysql/general.log），并永久禁用（my.cnf中设general_log = 0后重启）。
通用查询日志（general_log）开着就等于在狂写磁盘
MySQL 安装完默认不开启 general_log，但某些一键安装包、Docker 镜像或运维脚本会悄悄把它打开，且日志直接落到 /var/lib/mysql/ 下——这个目录通常和数据文件共用一个分区。一旦开启，每条 SQL（包括连接、断开、USE、SELECT * FROM mysql.user 这类元数据查询）都会被追加写入，几小时就能撑爆几十 GB。
检查是否中招，只用一条命令：
SHOW VARIABLES LIKE 'general_log%';
如果返回的 general_log 值是 ON，且 general_log_file 指向 /var/lib/mysql/xxx.log 类路径，基本就是它了。
- 立刻关闭：执行
SET GLOBAL general_log = OFF;（注意：仅对新连接生效，已有写入进程可能还在刷盘） - 确认日志文件没被 mysqld 占用：运行
lsof -n | grep mysql.*log，若有输出，kill -9对应 PID - 删日志前先清空内容更安全：
echo '' > /var/lib/mysql/general.log（比直接rm少风险，尤其当文件名被进程锁住时） - 永久禁用：在
my.cnf的[mysqld]段里加一行general_log = 0，然后重启
为什么不能直接 rm -f？ 因为 mysqld 可能还拿着文件句柄在写，rm 后空间不释放（df 不变），但 du 看不到该文件——这是 Linux 文件系统常见“假满”现象，清空内容才是最稳的救急动作。
purge binary logs 不解决 general_log 问题
很多人一看到磁盘满，条件反射跑 PURGE BINARY LOGS，但它只管 binlog，对 general_log 完全无效。两者日志类型、用途、开关方式、存储路径都不同，别混。
查完 general_log，顺手看 slow_query_log
慢日志也常被忽略。同样用 SHOW VARIABLES LIKE 'slow_query_log%'; 查状态。它默认关着，但如果被开过且长期没清理，也可能占几个 GB。处理逻辑和 general_log 一致：关掉 → 清空 → 配置里禁用。
真正棘手的是 ibdata1 或 binlog 积压，但它们不会“安装后瞬间占满”——那是日志类配置失控的典型特征。先盯死 general_log 和 slow_query_log，90% 的“刚装完就爆盘”问题就解了。
