真正有效的xtrabackup限速必须用流式备份（--stream）配合pv硬限速，因目录备份不经过stdout，pv和ionice均无法干预其直写io；--throttle仅控chunk频率，ssd/raid下限速效果差，而ionice只调优先级不设速率上限。
pv或--throttle控速；单纯调大innodb_io_capacity或加ionice对备份IO无实质压制。
为什么xtrabackup目录备份压不住IO
目录备份（如xtrabackup --backup --target-dir=/path）默认把数据块直写到磁盘，不经过stdout，所以pv -L、gzip等管道工具根本接不到数据。你看到的IO暴涨，是XtraBackup自己发起的大块顺序读+写，调度器没法节流。
-
ionice -c2 -n7只改IO优先级，不设速率上限；SSD或RAID下基本无效 -
--throttle=3在目录模式下控制的是每秒拷贝chunk数，但chunk默认10MB，实际IO仍可能突增 - 备份期间
innodb_buffer_pool_pages_dirty若持续上涨，说明redo日志追写跟不上，反而加剧刷盘压力
真正有效的限速组合：流式 + pv + 压缩
只有流式备份能把IO变成可控管道流，再用pv硬限速：
- 命令必须是：
xtrabackup --stream=tar ./ | pv -L 20m | gzip > backup.tar.gz -
-L 20m单位是字节/秒（20MB/s），不是IOPS；实测值需结合磁盘真实吞吐设（HDD建议≤8m，NVMe可到50m） - 不能写成
innobackupex /backup | pv -L 10m——innobackupex不输出到stdout，管道会卡死 - gzip级别选
-1（最快）或-6（平衡），避免CPU成为瓶颈拖慢整体流速
备份前必须检查的三个状态变量
IO高不一定是备份本身的问题，可能是底层已濒临临界：
-
Innodb_buffer_pool_pages_dirty：持续＞总页数70%，说明脏页积压，备份时触发Furious Flushing -
Innodb_buffer_pool_wait_free非零：前台线程正在等空闲页，此时备份会加剧阻塞 -
Innodb_log_waits＞0：redo log空间不足，checkpoint被迫频繁，把顺序写转成随机写，IO放大
这三个值任一异常，先别动备份脚本，得先调innodb_log_file_size和innodb_io_capacity。
云盘环境要额外防“隐性IO爆炸”
云厂商标称IOPS常含缓存，真实随机写能力打七折。比如AWS gp3标16000 IOPS，实测稳定值约11200，设innodb_io_capacity=11200后，备份流速仍建议控制在≤1/3，即pv -L 35m以内。
- 云盘
await＞20ms时，pv限速要再降30%，否则备份失败率升高 - 阿里云ESSD PL1盘有突发带宽，但持续写超配额后会被限速，
pv能防止触发该机制 - 备份目标挂载点若与MySQL数据目录同盘，
pv限速必须覆盖读+写双向流量
最易被忽略的是：流式备份成功后，gzip进程仍在后台写入，pv只管输入流速，不控最终落盘节奏——得用ionice -c2 -n7 gzip补一刀，但仅作为辅助，不能替代pv主控。
