mysql备份与空间优化核心是：用mysqldump | gzip直接压缩避免中间文件；安全清理binlog需确认主从同步；ibdata1无法收缩，应启用innodb_file_per_table；监控临时表落盘并优化sql。
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 表空间模型、查询执行机制的持续认知。最危险的操作，往往是以为“删了表就等于腾出空间”或者“压缩了备份就万事大吉”。
