MySQL磁盘爆满时，Writing to net或Copying to tmp table实为磁盘写入阻塞，需先定位/var/lib/mysql或/tmp分区瓶颈，再安全清理binlog、释放ibtmp1、调优tmp_table_size等参数治本。
MySQL磁盘爆满时，SHOW PROCESSLIST看到大量Writing to net或Copying to tmp table
这不是网络或查询慢的问题，是磁盘写不进去导致的阻塞。MySQL在写binlog、sort buffer溢出落盘、GROUP BY/ORDER BY生成临时表、InnoDB redo log轮转时都会猛写磁盘。一旦/var/lib/mysql所在分区使用率超95%，INSERT/UPDATE会直接报ERROR 3（比如ERROR 3: Error writing file '/tmp/...'），连FLUSH LOGS都可能卡住。
先别急着删文件——误删ib_logfile0或正在使用的mysql-bin.000123会导致实例崩溃。优先确认哪些能动：
-
SHOW VARIABLES LIKE 'datadir';查清数据目录位置，别在错的分区上操作 -
SHOW VARIABLES LIKE 'tmpdir';看临时文件写在哪，很多OOM其实是/tmp满了（尤其CentOS默认/tmp是内存盘） -
df -h /var/lib/mysql /tmp对比各路径使用率，定位真实瓶颈点
清理二进制日志前必须验证expire_logs_days是否生效
设了expire_logs_days = 7不等于日志自动消失——它只在FLUSH LOGS或MySQL重启时触发清理。更坑的是：如果从库IO线程还在读某个binlog（SHOW SLAVE STATUS\G里Relay_Master_Log_File指向mysql-bin.000100），哪怕过期了也不能删，否则主从断裂。
安全清理三步走：
- 查当前最老可用日志：
SHOW MASTER LOGS;记下File列第一个文件名 - 查从库延迟：
SELECT MASTER_POS_WAIT('mysql-bin.000100', 123456789);（用第一步的文件+位点）确认从库已追平 - 执行：
PURGE BINARY LOGS TO 'mysql-bin.000101';或PURGE BINARY LOGS BEFORE '2024-05-01 00:00:00';（注意时间是服务器本地时区）
别用rm -f mysql-bin.*，MySQL不会更新mysql-bin.index，下次启动可能报错。
innodb_file_per_table=OFF时，ibdata1无法收缩，但ibtmp1可以立刻释放
如果你的MySQL 5.7+用了共享表空间（innodb_file_per_table=OFF），删表后ibdata1体积纹丝不动——这是InnoDB设计限制，不是bug。但ibtmp1（InnoDB临时表空间）不同：它在服务重启时自动重建，默认大小为12MB，可暴涨到几十GB（尤其跑大排序或JSON处理时）。
立刻释放ibtmp1的方法：
- 确认没长事务：
SELECT * FROM information_schema.INNODB_TRX WHERE TIME_TO_SEC(TIMEDIFF(NOW(), trx_started)) > 60; - 执行：
ALTER TABLESPACE innodb_temp_tablespaces ENCRYPTION='N';（仅5.7.30+支持） - 或直接重启MySQL：
systemctl restart mysqld，重启后ibtmp1重置为初始大小
长期方案：在my.cnf加innodb_temp_data_file_path = ibtmp1:12M:autoextend:max:512M，防它无节制膨胀。
临时文件和SELECT导致的磁盘写入，重点盯tmp_table_size和max_heap_table_size
当SELECT语句的GROUP BY或ORDER BY结果集超过内存阈值，MySQL会把临时表写到磁盘，路径由tmpdir决定。常见现象是Created_tmp_disk_tables指标飙升，同时/tmp或/var/tmp迅速占满。
调参要点：
- 两个参数必须相等：
tmp_table_size = max_heap_table_size，否则以小的那个为准 - 设太高会吃光内存（比如设成2G，10个并发就20G），建议按物理内存20%~30%起步，再观察
SHOW GLOBAL STATUS LIKE 'Created_tmp%'; - 真正治本：给
ORDER BY字段加索引，或改写SQL避免SELECT *+ 大结果集排序
临时文件名形如#sql_XXXX_YYYY，千万别手动rm——可能正被某个连接读写，删了会触发ERROR 1030 (HY000): Got error 12 from storage engine。
磁盘空间问题最麻烦的从来不是“怎么删”，而是“删完又涨回来”。盯住Slow_queries和Created_tmp_disk_tables这两个状态变量，比清日志更能根治问题。
