mysqldump 加 --single-transaction
能否真正避免锁表
对 InnoDB 表有效，但仅限于事务隔离级别为
REPEATABLE READ且备份全程无 DDL 操作（如
ALTER TABLE、
DROP INDEX）。一旦有并发 DDL，
--single-transaction会隐式触发
FLUSH TABLES WITH READ LOCK，导致全局只读锁——这正是很多人“明明加了参数却还是卡住”的原因。
实操建议：
备份前检查是否有长事务：SELECT * FROM information_schema.INNODB_TRX WHERE TIME_TO_SEC(TIMEDIFF(NOW(), trx_started)) > 60;禁止在备份窗口内执行 DDL；可结合
pt-online-schema-change做在线变更 若必须备份 MyISAM 表，
--single-transaction无效，只能靠
--lock-tables=false+ 手动规避写入，或改用
mysqlpump（支持按引擎分策略）
使用 mysqlpump
替代 mysqldump
的实际收益
mysqlpump是 MySQL 5.7+ 官方推荐的并行逻辑备份工具，它默认启用
--default-parallelism=2，且能按库/表粒度并发导出，同时自动跳过不支持事务的引擎（如 MyISAM）并单独处理。
关键差异点：
mysqldump单线程 dump 全库，大表时 I/O 和 CPU 都集中在单个连接上
mysqlpump对每个表开独立连接导出，总耗时≈最长单表时间 / 并发数，但内存占用翻倍
mysqlpump --set-gtid-purged=OFF可避免 GTID 冲突，而
mysqldump默认开启且不可关 不支持
--master-data直接获取 binlog 位置，需额外执行
SHOW MASTER STATUS
物理备份（Percona XtraBackup
）何时必须上
当单库超 100GB、或要求 RPO mysqldump/
mysqlpump）已无法满足。XtraBackup 的热备份机制基于 InnoDB redo log 实时拷贝页，全程不阻塞 DML，但需注意： 备份期间仍会增加磁盘 I/O 压力，建议错峰执行，或用
--throttle限速（单位：IO ops/s）
xtrabackup --backup --target-dir=/path/to/backup后必须执行
--prepare才能恢复，跳过此步直接还原会导致数据不一致 MySQL 8.0+ 需用 XtraBackup 8.0+，且不兼容
data dictionary表空间分离场景（如
innodb_file_per_table=OFF） 备份目录权限必须为
mysql用户可读写，否则
--copy-back失败报错
Operating system error number 13 in a file operation
备份过程中的性能干扰如何量化监控
不能只看 CPU 或 load，重点盯三个指标：
复制延迟：Seconds_Behind_Master在主从架构下突增，说明备份加重了 relay log 应用压力 I/O 等待：
iostat -x 1中
%util持续 >90% 且
await> 50ms，表明磁盘已成瓶颈 InnoDB 状态：
SHOW ENGINE INNODB STATUS\G查看
SEMAPHORES下
os_waits是否激增，高值意味着 buffer pool 争用严重
线上环境建议把备份流量走专用网卡（
--socket=/tmp/backup.sock），并用
cgroups限制其 CPU 和 I/O 权重，避免挤压业务查询资源。
