先确认到底是哪个路径被塞爆了，运行df -h /var/lib/mysql /tmp /www定位高占用分区，再通过SHOW VARIABLES LIKE 'datadir'和'tmpdir'查清实际目录，区分可清空日志（如slow_query_log_file）、需轮转日志（log_error）及必须停库处理的文件（iblogfile0、ibtmp1），并配置binlog_expire_logs_seconds等参数防止复发。
先确认到底是哪个路径被塞爆了
别一看到 df -h 显示 100%，就去删 /var/lib/mysql 下所有文件——/tmp、/www/backup、甚至 /var/log 都可能是真凶。实际操作中，80% 的“磁盘满”问题根本不在 MySQL 数据目录里。
- 运行
df -h /var/lib/mysql /tmp /www，看哪个挂载点 Use% ≥95% - 查 MySQL 实际数据目录：
SHOW VARIABLES LIKE 'datadir';，确保你后续操作的是它所在的分区 - 查临时目录：
SHOW VARIABLES LIKE 'tmpdir';，有些环境/tmp是 tmpfs 内存盘，满了也会卡住 mysqld 启动 - 如果
/var/lib/mysql满了，重点盯mysql-bin.*、ibtmp1、slow.log；如果/www/backup满了，宝塔用户大概率是自动备份堆出来的
PURGE binary logs 前必须核对主从位点
直接执行 PURGE BINARY LOGS TO 'mysql-bin.000123'; 很危险：删掉从库还没读完的 binlog，主从立刻断裂，且无法自动恢复。
- 主库执行：
SHOW MASTER STATUS;，记下当前File（如mysql-bin.000124）和Position - 从库执行：
SHOW SLAVE STATUS\G，重点看Relay_Master_Log_File和Exec_Master_Log_Pos - 只有当从库的
Relay_Master_Log_File是mysql-bin.000123且Exec_Master_Log_Pos已到该文件末尾，才说明mysql-bin.000123可删，mysql-bin.000122及更早的才真正安全 -
Seconds_Behind_Master = 0不等于同步完成——IO 线程可能卡在旧日志上，必须看位点
哪些日志能立刻清空，哪些必须停库才能动
不是所有叫“日志”的文件都能随便删。MySQL 对不同日志的打开方式、写入机制完全不同，误删轻则启动失败，重则数据不可逆损坏。
- 可立刻清空（无需停库）：
slow_query_log_file（如/www/server/data/mysql-slow.log），但前提是先执行SET GLOBAL slow_query_log = OFF;，否则清空后立即重建 - 可轮转但不能删：
log_error（错误日志），用mysqladmin -u root -p flush-logs触发重命名，旧文件保留但不再写入 - 必须停库后删：
ib_logfile0、ib_logfile1（redo log），删前务必确认无未刷盘事务；mysql-bin.*文件也建议停库后PURGE，避免写入冲突 - 别碰
ibdata1：除非启用innodb_file_per_table，否则它不会收缩，删了等于删库
清理后必须堵住复发漏洞
一次清理只是救火，不改配置，一周内大概率再次爆满。最常被忽略的是 ibtmp1 和 binlog 自动清理策略。
- 设置 binlog 自动过期：
SET GLOBAL binlog_expire_logs_seconds = 2592000;（30 天），并写入my.cnf的[mysqld]段 - 限制单个 binlog 大小：
SET GLOBAL max_binlog_size = 1073741824;（1GB），防止单个文件过大难清理 -
ibtmp1是独立风险点：异常退出后不自动回收，且大小可能暴涨到几十 GB，停库后手动删/var/lib/mysql/ibtmp1是安全的 - 宝塔用户额外注意：
/www/backup/site/和/www/backup/database/下的 zip/gz 文件，用find ... -mtime +30 -delete定期清理
ibtmp1 还在涨、binlog 还在写、备份还在堆——这些默认不关闭的后台行为，才是磁盘反复告急的根源。 
