mysqldump + gzip 一步压缩备份文件
直接在管道里压缩，避免生成中间大文件，是节省磁盘空间最实际的做法。关键不是“能不能压”，而是“压完还能不能恢复”。
mysqldump输出是纯 SQL 文本，
gzip压缩后仍是标准流，用
zcat或
gunzip -c解开就能喂给
mysql，完全不影响还原逻辑 命令示例：
mysqldump -u root -p database_name | gzip > backup_$(date +%F).sql.gz如果服务器内存吃紧，加
--single-transaction（InnoDB）或
--lock-tables=false（谨慎用）减少锁表时间，避免备份卡住业务写入 别用
tar -z包一层——多此一举，还增加解包步骤；
.sql.gz是业界通用格式，工具链支持最稳
删除旧二进制日志释放空间
binlog 不是备份，但长期不清理会悄悄占满磁盘，尤其开启
binlog_format=ROW后体积增长极快。 先查当前状态：
SHOW BINARY LOGS;和
SHOW MASTER STATUS;看哪些还在用 安全清理方式是按时间删：
PURGE BINARY LOGS BEFORE '2024-06-01 00:00:00';，而不是盲目
PURGE BINARY LOGS TO 'mysql-bin.000123';配置文件里设
expire_logs_days = 7（MySQL 5.7）或
binlog_expire_logs_seconds = 604800（8.0+），避免人工遗漏 注意：主从架构下，必须确认所有从库
Seconds_Behind_Master = 0且
SHOW SLAVE STATUS\G中
Relay_Master_Log_File指向的日志仍存在，否则从库可能中断
清理 ibdata1 无法收缩的根本原因
ibdata1文件变大容易，变小几乎不可能——这不是操作失误，是 InnoDB 设计决定的。 即使删了所有表、执行
OPTIMIZE TABLE，
ibdata1里的系统表空间、undo log、数据字典仍保留，不会自动收缩 唯一可靠方法是：导出所有库（
mysqldump --all-databases），停 MySQL，删掉整个
data/目录（除
mysql系统库外要谨慎），再重装初始化，最后导入——这属于维护窗口操作，不能在线做 预防优于补救：从一开始就启用
innodb_file_per_table = ON（默认 5.6+ 已开启），让每张表有独立
.ibd文件，后续
DROP TABLE或
TRUNCATE才能真正释放磁盘空间
临时表与排序缓冲区导致的隐性空间占用
查询过程中产生的临时文件（
/tmp或
tmpdir）和内存不足溢出到磁盘的排序，常被忽略，但可能瞬间打爆磁盘。 检查是否频繁落盘：
SHOW GLOBAL STATUS LIKE 'Created_tmp%';中
Created_tmp_disk_tables占比高（比如 > 10%），说明
sort_buffer_size或
tmp_table_size/
max_heap_table_size设得太小 调参原则：不要全局设过大，优先优化 SQL（加索引、避免
SELECT *、拆分复杂 JOIN）；若必须调，建议单 session 设置：
SET SESSION sort_buffer_size = 4194304;确认 MySQL 的
tmpdir指向的是足够空间的分区（
SELECT @@tmpdir;），而不是根分区；必要时挂载单独磁盘并修改配置
空间优化不是一次性的清理动作，而是对 binlog 生命周期、InnoDB 表空间模型、查询执行机制的持续认知。最危险的操作，往往是以为“删了表就等于腾出空间”或者“压缩了备份就万事大吉”。
