cpulimit 能真正限制 mysqldump 进程的 CPU 使用，但仅对单次执行有效，无法限制 mysqld 本身；需通过 -e 或绝对路径+-- 启动，配合 -l（百分比）、-b、-z 等参数确保稳定运行。
cpulimit 能不能真正限制 mysqldump 进程的 CPU 使用
能，但只对单次执行的 mysqldump 有效——它无法限制 MySQL 服务本身（mysqld）的 CPU，只能约束备份命令进程。如果你用的是物理备份（如 mysqlbackup 或 xtrabackup），同样适用，但必须作用于其主进程 PID 或命令名。
常见错误是直接对 mysqld 进程限频，结果备份没压住，数据库响应反而变卡；或者限了 mysqldump 却忘了它默认会触发全表扫描+网络/磁盘 IO，CPU 降了但 I/O 瓶颈更明显。
- 确认目标进程：用
ps aux | grep mysqldump找到真实 PID，避免匹配到 shell 或 ssh 会话 - 优先用
-e按命令名限制（如cpulimit -e mysqldump -l 30），比 PID 更稳定（尤其脚本中启动多实例时） -
-l参数单位是百分比，不是核数：设-l 30表示最多用满 1 个逻辑核的 30%，在 8 核机器上 ≈ 总 CPU 的 3.75%
mysqldump + cpulimit 组合命令怎么写才不失败
关键在启动顺序和信号处理：cpulimit 必须在 mysqldump 进程创建后立刻 attach，否则有窗口期跑满 CPU。用 -b 后台模式 + -- 分隔符是最稳妥的写法。
典型失败场景：直接写 cpulimit -l 20 mysqldump ...，报错 failed to execute mysqldump: No such file or directory——因为 cpulimit 默认不解析 PATH，必须写绝对路径或加 --。
- 正确写法：
cpulimit -l 25 -b -- /usr/bin/mysqldump -u root -p database_name > backup.sql - 如果密码存在风险，改用配置文件：
cpulimit -l 20 -b -- /usr/bin/mysqldump --defaults-extra-file=/etc/mysql/backup.cnf database_name > backup.sql - 加
-z（自动退出）可避免备份中断后cpulimit还挂着：它检测到子进程退出就自行结束
为什么加了 cpulimit 备份还是慢，甚至失败
因为 CPU 不是唯一瓶颈。当强制压低 CPU 占用时，mysqldump 的单线程特性会被放大：压缩、加密、网络发送、磁盘刷写都排队等 CPU 时间片，整体耗时可能翻倍，还容易触发超时。
典型表现：备份日志里出现 MySQL server has gone away 或 Lost connection to MySQL server during query，其实是客户端等待时间过长被 kill。
- 调大 MySQL 的
wait_timeout和net_read_timeout（建议 ≥ 7200） - 禁用默认的
--opt中部分开销大的行为：--skip-opt --single-transaction --skip-triggers --skip-routines - 输出重定向不要用管道（如
| gzip），gzip 会额外争抢 CPU；改用mysqldump ... | gzip > backup.sql.gz并给 gzip 也限频：cpulimit -l 10 -- gzip -c > backup.sql.gz
有没有比 cpulimit 更可靠的替代方案
有，但要看环境。Linux cgroups v2 是更底层、更稳定的方案，能同时控 CPU、IO、内存，且不依赖进程存活状态。不过需要 root 权限和 systemd 支持，普通容器或共享主机上难落地。
另一个现实选择是换备份方式：mydumper 原生支持多线程 + CPU 限流（--threads + --throttle），比套壳 cpulimit 更干净；而 Percona XtraBackup 的 --throttle 参数直接控制每秒 IO 次数，对高负载系统更友好。
最容易被忽略的一点：很多“CPU 高”其实源于未优化的查询条件或锁表操作。检查 mysqldump 是否带了 --lock-tables（默认开启），换成 --single-transaction 可避免锁表导致的级联延迟。
