mysql因磁盘空间耗尽宕机本质是系统级enospc写入拒绝（error 28），须先用df -h精准定位/tmp、/var/log等真实满载分区，再依datadir和tmpdir路径分类清理binlog、ibtmp1或日志文件，严禁误删ibdata1或redo log。
MySQL因磁盘空间耗尽宕机，本质是系统级写入拒绝（Error 28），必须先定位真实满载路径，再分类清理——90% 的误操作源于删错了目录或文件类型。
df -h 看错分区，/tmp 或 /var/log 才是真凶
别一看到 df -h 显示 100%，就冲进 /var/lib/mysql 目录删文件。实际常见爆满点是：/tmp（尤其当 tmpdir 指向它且为 tmpfs）、/var/log（如 catalina.out、docker/containers/*-json.log）、/www/backup（宝塔自动备份堆积）。运行以下命令快速聚焦：
-
df -h /var/lib/mysql /tmp /var/log /www—— 只查这几个关键挂载点，看哪个 Use% ≥ 95% -
mysql -u root -p -e "SHOW VARIABLES LIKE 'datadir';"—— 确认 MySQL 实际数据目录挂在哪块盘 -
mysql -u root -p -e "SHOW VARIABLES LIKE 'tmpdir';"—— 查清临时文件写入位置，避免误判
du -sh * | sort -hr 定位大文件，但别信 information_schema.TABLES
information_schema.TABLES 返回的是估算值，物理占用以磁盘文件为准。进入真正满载的目录后，用 du 直接看实体：
-
cd /var/lib/mysql && du -sh * | sort -hr | head -10—— 快速列出最大的库/文件，重点关注mysql-bin.*、ibtmp1、slow.log -
du -sh *.ibd | sort -hr | head -5—— 若某库下.ibd文件巨大，说明是单表膨胀（需结合innodb_file_per_table状态判断是否可收缩） -
lsof +L1—— 查找已被rm但进程仍在写入的“已删除但未释放”文件（常见于日志轮转失败场景）
PURGE BINARY LOGS 前不核对主从位点，等于主动断主从
直接 PURGE BINARY LOGS TO 'mysql-bin.000123'; 是高危操作。必须人工比对主从状态：
- 主库执行：
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可删；更早的才真正安全 -
Seconds_Behind_Master = 0≠ 同步完成——IO 线程可能卡在旧 binlog 上，必须看位点
ibtmp1 和 ibdata1 处理逻辑完全不同，混着删会丢数据
这两类文件常被一起列在“大文件”清单里，但机制和处置方式截然不同：
-
ibtmp1：InnoDB 临时表空间，MySQL 停止后不会自动清理，可直接rm /var/lib/mysql/ibtmp1（重启后重建），无需停库前特殊操作 -
ibdata1：共享表空间，若innodb_file_per_table = OFF，所有表数据都挤在里面，删了等于删库；即使= ON，它仍存 undo 日志和系统元数据，不能删，只能通过全量导出+重建来收缩 - 误删
ib_logfile0/ib_logfile1（redo log）会导致启动时崩溃，必须先设innodb_fast_shutdown = 0正常关闭，再删
真正难处理的从来不是 binlog 占满——而是 ibdata1 在共享模式下只增不减，或 ibtmp1 因长事务持续膨胀却无人监控。每次清理后，务必检查 error.log 末行是否还有 No space left on device，并确认 tmpdir 权限为 mysql:mysql，否则重启仍会失败。
