必须先定位真实满载挂载点（如/tmp、/www/backup等），再依datadir/tmpdir确认路径；binlog和ibtmp1严禁rm删除，须用purge或停库清理，否则导致启动报错或日志跳过。
直接删 mysql-bin.* 或 ibtmp1 文件大概率会让 MySQL 启动报错甚至跳过日志，必须先定位真实满载点、区分文件类型、按机制清理。
先确认到底哪个挂载点满了，别只盯 /var/lib/mysql
90% 的“MySQL 启动失败”不是数据目录真满了，而是 /tmp、/var/log、根分区或 /www/backup（宝塔用户常见）占满。运行：
-
df -h /var/lib/mysql /tmp /www /var/log /—— 看哪一行Use%≥ 95% -
mysql -u root -p -e "SHOW VARIABLES LIKE 'datadir';"—— 确认 MySQL 实际数据目录挂在哪块盘上 -
mysql -u root -p -e "SHOW VARIABLES LIKE 'tmpdir';"——/tmp是 tmpfs 内存盘时，满了也会卡住启动
哪些日志能立刻清空，哪些必须进 MySQL 才能动
误删会破坏一致性，MySQL 启动时可能拒绝加载表空间或跳过 binlog：
linux-performance-analyzer
下载
Linux 性能分析与调优专家，覆盖 CPU、内存、磁盘 I/O、网络、内核参数、编译优化、容器/K8s。适用场景：系统卡顿/高负载、内存不足/OOM/Swap 高、CPU 异常/iowait 高。
- 可安全截断（不需停库）：
slow_query_log_file（如/www/server/data/mysql-slow.log），先执行SET GLOBAL slow_query_log = OFF;，再echo "" > /path/to/file.log - 可轮转但不能删：
log_error对应的错误日志，用mysqladmin -u root -p flush-logs触发重命名 - 必须进 MySQL 才能删：
mysql-bin.*，只能用PURGE BINARY LOGS TO 'mysql-bin.000123';或PURGE BINARY LOGS BEFORE '2026-08-01 00:00:00';，禁用rm - 必须停库后删：
ibtmp1（常驻几十 GB 不释放）、ib_logfile0/1（redo log），删前确保innodb_fast_shutdown = 0并已正常关闭 mysqld
连 mysql 客户端都连不上，怎么执行 PURGE
磁盘满到连 socket 都建不了时，常规连接会失败，但仍有办法进 MySQL 执行命令：
- 用
mysqld_safe --skip-grant-tables &启动（跳过权限检查），然后mysql -u root直连 - 若仍失败，说明
tmpdir所在分区（如/tmp）已满，先清理该路径下大文件，或临时改tmpdir到有空间的目录（需改配置并重启 mysqld_safe） - 清理后不要直接
systemctl start mysql，先手动运行mysqld --defaults-file=/etc/my.cnf --user=mysql测试能否跑起来，避免 systemd 静默失败
清理完还起不来？重点查这三处残留
释放空间 ≠ 自动恢复，MySQL 启动时仍可能因状态残留失败：
- 检查
/var/log/mysql/error.log最末几行是否还有No space left on device—— 说明还有被删除但未释放的文件，用lsof +L1找出并kill对应进程 - 如果看到
InnoDB: Unable to lock ./ibdata1，大概率是innodb_file_per_table = OFF导致ibdata1膨胀且无法收缩，此时删表不缩空间，只能导出重建 - 确认
tmpdir目录权限正确：chown mysql:mysql /tmp（若 tmpdir 是/tmp），否则启动时创建临时文件失败
真正难处理的从来不是 binlog 占满，而是 ibdata1 在共享表空间模式下持续膨胀，且删不掉、缩不了——这种场景下，清理只是临时止血，长期得切到 innodb_file_per_table = ON 并逐步迁移。
