真正可控的是拆解写入节奏、控制并发粒度、并临时调低innodb刷盘强度；pv -l导入更可靠因在写入侧流控，需配合禁用事务强制刷盘（如set innodb_flush_log_at_trx_commit=2）才能生效。
直接限制 mysqldump 进程的 IO 无效——它不暴露限速接口，靠 ionice 或 cpulimit 压制只会让连接超时或导入中断。真正可控的是拆解写入节奏、控制并发粒度、并临时调低 InnoDB 的刷盘强度。
为什么 pv -L 配合 mysql 导入比压 mysqldump 更可靠
因为 mysqldump 是只读导出端，IO 压力在目标库；而 pv -L 5m | mysql db_name 是在导入侧做流控，能直接掐住写入速率。关键点在于：必须配合禁用事务强制刷盘，否则 pv 限速会被单条 INSERT 的 fsync 打穿。
- 导入前执行：
SET GLOBAL innodb_flush_log_at_trx_commit = 2;和SET GLOBAL sync_binlog = 0;（迁移完必须改回） - 大表导入优先用
--skip-extended-insert，避免单行 SQL 过长触发日志切片 - 若导入脚本含
COMMIT，需确保每批不超过 1000 行，否则仍会触发批量刷盘
用 mysqlpump 分表并行导出时，哪些参数真能压住 IO
mysqlpump 本身不限速，但它的表级并发和分片能力，让外部限速工具更容易生效。重点不是开多少线程，而是不让多个表同时刷脏页。
- 用
--default-parallelism=2控制并发线程数，超过 4 容易引发 IO 抢占 - 对单表加
--where="id BETWEEN 1 AND 50000"拆成小块，再拼接导入，比全表 dump +pv更稳 - 导出时加
--skip-triggers --no-create-db --skip-definer，减少元数据 IO - 注意：MySQL 5.7.8+ 才支持
mysqlpump，且遇到视图会报Unknown error
物理迁移中，哪个环节最该限速
xtrabackup 的备份阶段本身就会打满 IO，但它的优势是“备份后限速”——压缩、拷贝、解压三个环节可独立控制，比逻辑迁移更可控。
- 备份时不加
--compress-threads，改用--compress --compress-threads=1，避免多线程压缩吃光 CPU 和 IO - 拷贝到目标机用
rsync --bwlimit=10000（单位 KB/s），比scp更稳定、可断点续传 - 恢复前先跑
innobackupex --apply-log --use-memory=2G /path，内存不足会退化成磁盘排序，IO 翻倍 - 别忘了：所有限速都依赖实时感知，
iostat -x 1得开着看，尤其盯%util和await
最常被忽略的是：所有限速手段都依赖对当前 IO 负载的实时感知，iostat -x 1 得开着看。
