应先执行df -h /tmp和df -h /backup确认两路径所在分区空间，再运行df -i /tmp检查inode是否耗尽，因mysqldump默认用/tmp做临时缓冲，大表导出会先写满/tmp再压缩，即使备份路径有空间，同挂载点仍会失败。
mysqldump导出报“No space left on device”怎么快速定位
不是磁盘真满了，而是mysqldump默认用/tmp做临时缓冲区，大表导出会先写满/tmp再压缩。哪怕你把备份存到/backup，只要/tmp和/backup在同一个挂载点（比如都落在/），就会爆。
立刻执行：df -h /tmp 和 df -h /backup（把/backup换成你实际路径）
再补一句：df -i /tmp——小文件极多时，inode 可能先耗尽。
-
information_schema.TABLES里的DATA_LENGTH是估算值，比真实.ibd文件小20%–30%，别信它来判断空间余量 -
du -sh /var/lib/mysql总和远小于df -h显示已用？大概率是“幽灵文件”，用lsof +L1查已删但进程仍打开的句柄
备份前如何避免生成超大单文件
单个SQL文件超过4GB，在FAT32/NTFS上直接写失败（EFBIG错误），这不是MySQL问题，是文件系统硬限制。
- 强制分表导出：
mysql -e "SHOW TABLES FROM your_db" | tail -n +2 | xargs -I{} mysqldump -u user -p your_db {} | pigz > {}.sql.gz，每个表独立压缩，天然规避单文件超限 - 若必须逻辑统一备份，改用
xtrabackup --stream=xbstream . | pigz > full.xbstream.gz——xbstream格式无单文件大小限制，且支持后续解包还原 -
--skip-extended-insert会让SQL体积暴增，必须保留默认的--extended-insert
大表导出卡死或OOM怎么办
单表千万行+TEXT/BLOB字段时，mysqldump会把整张表加载进内存拼SQL，max_allowed_packet对它无效。
- 加
--single-transaction（InnoDB）或--lock-tables=false（MyISAM），避免全表锁阻塞业务 - 禁用
--opt（它隐含--add-drop-table等），显式精简：mysqldump -u u -p --no-autocommit --skip-triggers --compact your_db table_name - 用
--where分批导出，例如--where="created_at >= '2025-01-01' AND created_at ，配合脚本循环生成季度备份
gzip压缩后仍超配额，还能怎么减体积
换pigz只能提速，压缩率改善有限。真正减体积得动数据结构本身：
- 导出前执行
OPTIMIZE TABLE回收已删除行空间（注意：锁表，建议从库低峰期执行） - 用
--ignore-table=db.audit_log跳过纯日志表；用--no-create-info省掉CREATE语句（若已有建表脚本） - 对JSON/TEXT字段，若业务允许，导出前临时截断：
UPDATE sensitive_table SET payload = LEFT(payload, 1000) WHERE LENGTH(payload) > 1000
最易被忽略的是/tmp分区和inode耗尽——很多故障根本不是数据库文件太大，而是临时缓冲区先崩了。
