直接改mysqldump的--tmpdir参数比清理/tmp更快更稳，它不依赖MySQL重启、不触碰系统临时目录，且能规避inode耗尽问题；mysqldump只认操作系统级临时目录或显式指定的--tmpdir，与MySQL的@@tmpdir无关。
直接改 mysqldump 的临时目录路径，比清理 /tmp 更快、更稳——它不依赖重启 MySQL，也不碰系统临时文件，还能避开 inode 耗尽这种隐形坑。
确认到底是哪个路径卡住了
别凭经验猜。mysqldump 默认用系统 /tmp 写临时 SQL 文件和压缩缓冲区，但如果你的备份目标路径（比如 /backup）和 /tmp 在同一挂载点，实际是两个地方一起挤爆的。先查清楚：
- 运行
df -h /tmp和df -h /backup（把/backup换成你脚本里真实写的路径）；如果两者显示同一个挂载点（如都是/），那问题大概率出在这儿 - 再补一句：
df -i /tmp——尤其当备份脚本生成大量小文件（如分表导出、带--skip-triggers多次调用），inode 可能先用完，df -h还显示有空间 -
mysqldump不读 MySQL 的@@tmpdir变量，它只认操作系统级的临时目录或你显式传的--tmpdir
临时救急：加 --tmpdir 参数重跑
这是最立竿见影的办法，不用改配置、不重启服务、不清理旧文件：
- 选一个剩余空间 ≥ 预估备份大小 × 1.5 的目录，比如
/data/tmp；确保该路径存在、MySQL 进程用户（通常是mysql）有读写权限 - 命令里直接加参数：
mysqldump --tmpdir=/data/tmp -u root -p mydb > /backup/mydb.sql - 注意：
--tmpdir只影响mysqldump自己生成的临时文件（如未压缩的 SQL 流、gzip 中间缓冲），不影响innodb_tmpdir或内部排序行为 - 如果用的是
xtrabackup，它不认这个参数，得换环境变量：TMPDIR=/data/tmp innobackupex --defaults-file=/etc/my.cnf ...
脚本里加空间校验，别等失败了再擦屁股
半截失败的备份最难处理：残留临时文件占着空间、下一次又卡住、还可能干扰后续恢复。真正在意稳定性的脚本，开头就得拒绝启动：
- 校验必须覆盖两处：
/tmp（没设--tmpdir时默认用它）和你的备份目标路径（如/backup） - 别信
information_schema.TABLES.DATA_LENGTH，它比真实.ibd小 20%–30%，容易误判余量 - 示例检查逻辑（Bash）：
BACKUP_DIR="/backup"<br>THRESHOLD=85<br>USAGE=$(df "$BACKUP_DIR" | awk 'NR==2 {print $5}' | sed 's/%//')<br>if [ "$USAGE" -gt "$THRESHOLD" ]; then<br> echo "ERROR: $BACKUP_DIR usage ${USAGE}%, aborting backup"<br> exit 1<br>fi - 顺手加
set -e，保证任意命令失败立刻退出，避免继续往下执行
长期别碰 /tmp，但得盯住三个吃空间大户
很多团队只清 binlog，却忽略真正撑爆磁盘的是这些：
-
general_log和slow_query_log：开启后不轮转，单个日志文件轻松几 GB；关掉立刻释放：SET GLOBAL general_log = 'OFF';，再rm对应文件 -
ibtmp1：MySQL 5.7+ 默认启用，升级或重启后可能从 12MB 猛涨到几十 GB，且不会自动收缩；长期方案是在my.cnf加innodb_temp_data_file_path = ibtmp1:12M:autoextend:max:2G -
tmpfs挂载的/tmp：CentOS 默认是内存盘，大小常只有 1–2GB；即使你改了mysqldump --tmpdir，其他工具（如CREATE TABLE AS SELECT）仍会撞上它
真正麻烦的不是空间本身，而是不同组件对“临时目录”的理解不一致——mysqldump、MySQL server、系统 libc 全用各自的规则找路径，稍不注意就漏掉一处。
