磁盘爆满时INSERT/UPDATE/SHOW PROCESSLIST失败是因写入被内核阻塞，非MySQL宕机；需先用df -h定位/var/lib/mysql、/tmp或/var/log中>95%的瓶颈分区，再依SHOW VARIABLES查datadir/tmpdir精准操作，严禁误删ibdata1或redo log。
磁盘空间爆满时，INSERT、UPDATE、甚至 SHOW PROCESSLIST 都会失败，并不是 MySQL 挂了，而是写入被内核阻塞——Writing to net 和 Copying to tmp table 这类状态实际是磁盘写不进去的假象。
先定位真实瓶颈分区，别在错的路径上操作
MySQL 写满不等于 /var/lib/mysql 满，也可能是 /tmp 或 /var/log。误删或清理错位置，不仅白忙，还可能触发崩溃。
- 查数据目录：
SHOW VARIABLES LIKE 'datadir';—— 看清ibdata1、ib_logfile*、mysql-bin.*实际落在哪一分区 - 查临时目录：
SHOW VARIABLES LIKE 'tmpdir';—— 很多GROUP BY或大排序落盘到/tmp，而 CentOS 默认/tmp是内存盘（tmpfs），撑爆后直接 OOM - 实测占用：
df -h /var/lib/mysql /tmp /var/log—— 对比各挂载点使用率，只动 >95% 的那个
PURGE BINARY LOGS 前必须验证从库追平状态
expire_logs_days = 7 不等于日志自动删除；它只在 FLUSH LOGS 或重启时触发，且绝不删仍在被从库读取的 binlog。强行 rm -f mysql-bin.000123 会导致主从断裂，mysql-bin.index 不同步还会让 MySQL 启动报错。
- 查当前最老 binlog：
SHOW MASTER LOGS;记下第一行File名（如mysql-bin.000100） - 确认从库是否已读完：
SELECT MASTER_POS_WAIT('mysql-bin.000100', 123456789);（位点用SHOW SLAVE STATUS\G中的Exec_Master_Log_Pos）返回非NULL才安全 - 执行清理：
PURGE BINARY LOGS TO 'mysql-bin.000101';或PURGE BINARY LOGS BEFORE '2026-04-01 00:00:00';（注意时区是服务器本地时间）
释放 ibtmp1 临时表空间无需重启，但得避开长事务
ibtmp1 是 InnoDB 临时表空间，默认 12MB，但跑大 JSON 解析、ORDER BY 或未提交事务时可暴涨至几十 GB。它和 ibdata1 不同：服务重启即重建，且支持运行时收缩（5.7.30+）。
- 先确认没活跃长事务：
SELECT * FROM information_schema.INNODB_TRX WHERE TIME_TO_SEC(TIMEDIFF(NOW(), trx_started)) > 60;—— 若有结果，先评估是否能 kill - 收缩命令（仅限 MySQL 5.7.30+）：
ALTER TABLESPACE innodb_temp_tablespaces ENCRYPTION='N';—— 这会强制重建临时表空间，立刻释放磁盘 - 若版本低于 5.7.30，只能等空闲期重启，或临时调大
tmp_table_size和max_heap_table_size减少落盘频率
别碰 ibdata1 和 redo log，除非你准备停库重建
ibdata1 在 innodb_file_per_table=OFF 时无法收缩，删表、OPTIMIZE TABLE 全无效；ib_logfile0/ib_logfile1 是 redo log，删了 MySQL 启动直接报错 InnoDB: Error: log file ./ib_logfile0 is of different size。
- 安全做法：停库 → 备份
my.cnf中的innodb_log_file_size值 → 删ib_logfile*→ 启动（MySQL 自动重建） - 根本解法（仅适用于共享表空间）：导出全量数据 → 停库 → 删
ibdata1+ib_logfile*→ 配置启用innodb_file_per_table=ON→ 重建并导入 —— 这是唯一能让ibdata1“变小”的方式 - 日常预防：把慢日志、通用日志关掉（
SET GLOBAL slow_query_log = OFF;），再删对应文件；它们是唯一能直接rm且不伤服务的日志
真正棘手的从来不是“删哪个文件”，而是“删完会不会让正在跑的事务回滚失败”或者“从库还没读完就 purge”。所有清理动作前，务必确认复制位点、事务活跃度、配置一致性——磁盘满了是症状，不是病因。
