mysql压缩备份cpu飙升是因为逻辑备份本身需大量select查询，叠加管道压缩（如gzip/zstd）使cpu同时承担数据读取与实时压缩双重计算压力；--compress仅启用网络层压缩，不影响本地备份cpu负载。
MySQL压缩备份为什么CPU飙升？
因为压缩不是“免费的”，它把磁盘I/O压力转嫁成了CPU计算压力。mysqldump本身是逻辑备份，本质是一连串SELECT查询；再加上--compress或管道用gzip/zstd，就等于让CPU一边读数据、一边实时压缩——两件事叠在一起干，CPU自然顶不住。
mysqldump --compress 和管道压缩的区别在哪？
很多人以为加了--compress参数就能省资源，其实它只启用MySQL客户端和服务端之间的**网络层压缩**（ZLIB），对本地备份文件没影响，也不降低CPU负载。真正吃CPU的是你手动加的管道压缩：
-
mysqldump db | gzip > backup.sql.gz→ gzip进程独占CPU核心，尤其在多核机器上可能打满1个核 -
mysqldump db | zstd -T0 > backup.sql.zst→-T0表示用满所有核，压缩快但更抢资源 - 不压缩直接写磁盘：
mysqldump db > backup.sql→ CPU低，但IO高、占空间大
注意：--compress和gzip完全无关，别混用，否则徒增无效开销。
哪些场景会让压缩CPU开销特别大？
不是所有数据都适合边导出边压缩。以下情况会显著放大CPU压力：
- 表里有大量
TEXT/BLOB字段：这些内容本身冗余低，压缩率差，但CPU照常算 - 使用
zstd -1或gzip -9：高压缩率=高计算量，zstd -3通常性价比更好 - 备份时并发跑多个压缩任务：比如并行dump多个库+各自gzip，CPU争抢激烈
- Buffer Pool未预热，大量物理读触发磁盘I/O + 压缩双压CPU
实测：一张5GB的InnoDB表，mysqldump | gzip -6平均占用1.8个CPU核心；换成zstd -3后降到1.2个，且总耗时还缩短11%。
有没有既压缩又不猛刷CPU的办法？
有，但得放弃“一步到位”的幻想。关键思路是**拆开做、错峰做、选对工具**：
- 先用
mysqldump --single-transaction --skip-triggers > backup.sql无压缩导出（CPU友好） - 再用
ionice -c2 -n7 nice -n19 zstd -T1 -3 backup.sql -o backup.sql.zst单独压缩（降I/O+降CPU优先级） - 或者用
pxz（parallel xz）替代gzip，它能限制线程数：mysqldump db | pxz -T2 -3 > backup.sql.xz - 真正想省CPU，就别用逻辑备份：Percona XtraBackup物理备份几乎不走SQL引擎，压缩由备份工具在页级别完成，CPU开销低得多
最后提醒一句：压缩率≠实用性。一个从10GB压到3GB的备份，如果解压要花8分钟、且每次恢复都卡在CPU上，那它只是把问题从磁盘搬到了CPU。盯住的是恢复RTO，不是压缩比数字。
