mysql磁盘满导致无法启动时，应先定位/var/lib/mysql或/tmp分区占用率≥95%的具体路径，再通过show variables确认datadir和tmpdir位置；若为binlog占满，须验证主从同步位点后用purge命令安全清理，禁用rm删除；清理后需设置binlog_expire_logs_seconds、max_binlog_size等参数防复发，并注意ibtmp1暴涨的独立风险。
MySQL磁盘空间满导致无法启动，大概率是 /var/lib/mysql 分区被 binlog 塞爆了——这不是配置问题，是写入阻塞引发的连锁故障。直接删文件会破坏 mysql-bin.index，重启后可能报错或跳过日志，必须进 MySQL 用 PURGE 命令清理。
确认磁盘瓶颈在哪个路径
别猜，先定位真实占用点：
- 运行
df -h /var/lib/mysql /tmp，看哪个分区使用率 ≥95% - 查 MySQL 数据目录：
SHOW VARIABLES LIKE 'datadir';，确保你操作的是它所在的挂载点 - 查临时文件位置：
SHOW VARIABLES LIKE 'tmpdir';，有些环境/tmp是内存盘（tmpfs），满了一样卡住 - 如果
/var/lib/mysql满了，重点盯mysql-bin.*和ibtmp1；如果/tmp满了，Copying to tmp table类错误就是假象，实为磁盘写不进去
清理binlog前必须验证从库同步状态
误删正在被从库读取的 binlog，主从立刻断裂。不能只看时间，得看位点：
- 在主库执行：
SHOW MASTER STATUS;，记下File（如mysql-bin.000123）和Position - 在从库执行：
SHOW SLAVE STATUS\G，检查Relay_Master_Log_File和Exec_Master_Log_Pos - 确认从库已追平：比如主库当前是
mysql-bin.000123位置 123456789，从库Relay_Master_Log_File是mysql-bin.000122、Exec_Master_Log_Pos已到该文件末尾，说明mysql-bin.000123可安全保留，mysql-bin.000122及更早的才可删 - 别信
Seconds_Behind_Master = 0就万事大吉——它只反映 SQL 线程延迟，IO 线程可能卡在旧日志上
用PURGE命令安全删除binlog，别用rm
rm -f mysql-bin.000* 会留下脏索引，MySQL 启动时可能拒绝加载或跳过后续日志：
- 按文件名删（推荐）：
PURGE BINARY LOGS TO 'mysql-bin.000123';—— 删除所有 早于mysql-bin.000123的日志（不含该文件本身） - 按时间删（注意时区）：
PURGE BINARY LOGS BEFORE '2026-04-28 00:00:00';—— 时间是 MySQL 服务器本地时区，不是 UTC - 删完立刻生效，无需重启；但要触发自动清理逻辑（比如让过期策略起作用），可补一句
FLUSH LOGS; - 如果连 MySQL 客户端都连不上（socket 拒绝、启动卡死），先用
mysqld_safe --skip-grant-tables &启动跳过权限检查，再连上去执行PURGE
清理后必须调参防复发
清完只是救火，不调参一周内还会爆：
- 设自动过期（MySQL 8.0+ 必用）：
SET GLOBAL binlog_expire_logs_seconds = 604800;（7天），并写入my.cnf的[mysqld]段，避免重启失效 - 禁用
expire_logs_days：它和binlog_expire_logs_seconds冲突，设为 0 更稳妥 - 限制单个 binlog 大小：
max_binlog_size = 1024M，防止单个文件过大拖慢 PURGE - 如果没主从，且不需要基于时间点恢复，干脆关掉 binlog：
skip-log-bin（需重启，慎用）
真正容易被忽略的点是：ibtmp1 也能暴涨几十 GB 占满磁盘，但它和 binlog 无关，删 binlog 解不了它的锁。遇到 Writing to net 却查不到大 binlog，就得查 INNODB_TRX 和临时表空间状态——那已是另一个故障域了。
