--single-transaction 对 InnoDB 表有效，但需满足 REPEATABLE READ 隔离级别且无并发 DDL；否则会触发 FLUSH TABLES WITH READ LOCK 导致锁表。
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 权重，避免挤压业务查询资源。
