mysqldump自身不支持网络带宽限速，因其无--bandwidth-limit等参数，仅生成SQL流而不控制传输速率；net_write_timeout和max_allowed_packet仅影响连接稳定性与包大小，非速率控制器；压缩不降低瞬时带宽；唯一可靠方案是用pv在管道中硬限速，如mysqldump | pv -L 2m > backup.sql。
不能靠 mysqldump 或 MySQL 服务端参数限速，必须在数据流管道上做带宽控制。
为什么 mysqldump 自身不支持网络带宽限速
mysqldump 没有 --bandwidth-limit 或类似参数；它只管生成 SQL 流，不管传输层速率。设置 net_write_timeout 或 max_allowed_packet 只影响连接稳定性或单次包大小，不控制平均吞吐。强行调小这些值反而容易触发中断或重连，导致备份失败。
-
net_write_timeout=1000是超时阈值，不是速率控制器 -
max_allowed_packet=1M会让大表导出变慢，但属于“卡顿式降速”，不可控、不均匀、易出错 - 压缩（
--compress）只减少体积，不降低瞬时带宽占用；网络链路仍可能在解压瞬间打满
用 pv 在管道中硬限速（推荐方案）
这是最直接、可靠、跨平台的方式：把 mysqldump 输出塞进 pv，再重定向到文件或远程目标。它按字节/秒恒定压制输出流，对公网带宽有明确约束力。
- 安装：
apt install pv（Debian/Ubuntu）或yum install pv（CentOS/RHEL） - 本地限速备份：
mysqldump -u root -p mydb | pv -L 2m > backup.sql（限制为 2MB/s） - 远程限速备份：
mysqldump -u root -p mydb | pv -L 500k | ssh user@remote "cat > /backup/backup.sql"（限制为 500KB/s） -
-L单位支持k、m、g，例如-L 10m= 10MB/s；加-q可静默运行
远程物理备份（Xtrabackup）如何限速
当使用 innobackupex 或 xtrabackup 做流式远程备份时，--throttle 控制的是本地 I/O，不是网络带宽。要限公网，依然得靠 pv 插在管道里。
- 错误做法：
innobackupex --stream=tar /data | ssh ...→ 网络全速跑 - 正确做法：
innobackupex --stream=tar /data | pv -q -L 3m | ssh ...→ 明确压到 3MB/s - 注意：
pv必须放在| ssh之前，否则限速发生在远端，已无意义 - 如果远端磁盘慢，
ssh进程会背压，pv自动节流，不会丢数据
云平台 DTS 或备份服务的限速陷阱
阿里云 DTS、腾讯云 CDB 备份等托管服务虽提供“限速”开关，但其粒度粗、反馈滞后，且常仅作用于内部线程调度，不等于网络出口带宽可控。
- DTS 的
全量导出 RPS是每秒行数，和字节带宽无直接换算关系 - “备份网络限速”参数仅对 MySQL 物理备份链路生效（如阿里云 DMS），逻辑备份（
mysqldump类）不支持 - 一旦设置过低（如
--throttle=1），Xtrabackup 可能卡死在xtrabackup_logfile写入阶段，实际备份永远完不成 - 真正要保公网不被打满，唯一可信赖的仍是
pv这类用户态流控工具
真正难的不是加限速，而是确定那个“不打满又不太慢”的值——建议从 1MB/s 起步，观察 5 分钟内公网出口带宽监控曲线，再逐步上调。别信理论值，只信你服务器网卡实时吐出来的字节数。
