mysqldump加--single-transaction可避免锁表但仅对InnoDB有效，利用MVCC快照实现无锁备份；mysqlpump支持多线程并行备份；Percona XtraBackup提供真正零锁物理备份。
mysqldump 加 --single-transaction 能避免锁表，但仅对 InnoDB 有效
MySQL 默认的 mysqldump 在备份时会执行 FLUSH TABLES WITH READ LOCK（除非显式禁用），导致整个实例只读，业务写入阻塞。对 InnoDB 表，加 --single-transaction 可绕过全局锁：它利用 MVCC 在事务快照中读取数据，全程不阻塞 DML。
- 必须确保所有待备份表都是
InnoDB引擎，MyISAM表仍会被锁（哪怕加了该参数） - 备份开始前需确认
autocommit=1，否则事务不会自动开启，快照无法建立 - 大表或长事务会导致快照一致性窗口拉长，可能引发
ERROR 1205 (HY000): Deadlock found或备份超时 - 不适用于有 DDL 操作的场景——
ALTER TABLE等会中断一致性快照，报错Cannot execute statement in a READ ONLY transaction
用 mysqlpump 替代 mysqldump 提升并发备份能力
mysqlpump 是 MySQL 5.7+ 提供的并行逻辑备份工具，原生支持多线程导出、按库/表粒度分片、自动跳过锁表操作，比 mysqldump 更适合高并发环境。
- 默认启用
--single-transaction，且对每个数据库单独启事务，降低长事务影响 - 用
--default-parallelism=N控制线程数（如N=4），但注意不要超过服务器 CPU 核心数 × 2 - 不支持
MyISAM表的无锁备份，遇到时会自动退化为表级LOCK TABLES，需提前检查引擎类型 - 导出的 SQL 中包含
SET SESSION binlog_format=ROW，若目标环境禁用 row 格式会报错，需提前清理或加--skip-binlog
物理备份（Percona XtraBackup）是真正零锁的方案
逻辑备份本质是查数据再拼 SQL，I/O 和 CPU 压力大，且无法做到严格时间点一致；而 Percona XtraBackup 直接拷贝 InnoDB 数据文件，通过 replay redo log 实现最终一致性，全程不锁表、不阻塞业务。
- 备份时主库持续接受写入，
xtrabackup仅在最后几秒做FLUSH TABLES WITH READ LOCK获取 binlog 位点，锁时极短 - 要求 MySQL 开启
innodb_file_per_table=ON，否则无法精确备份单表 - 恢复前必须执行
xtrabackup --prepare，否则启动 MySQL 会报错InnoDB: Database page corruption on disk - 不兼容 MySQL 8.0 的数据字典表（
mysql.ibd），8.0+ 需用mysqlbackup或xbstream流式备份
备份期间的并发安全关键配置项
无论选哪种备份方式，以下配置直接影响并发表现和数据一致性：
-
innodb_lock_wait_timeout：建议设为600（默认 50），避免备份脚本因锁等待被 kill -
max_connections：备份进程本身占连接，需预留足够余量，否则业务连接会报ERROR 1040 (HY000): Too many connections -
innodb_log_file_size：过小会导致频繁 checkpoint，拖慢备份速度；过大则--prepare时间变长 - 备份命令中务必加
--set-gtid-purged=OFF（GTID 环境下），否则可能触发ERROR 1236 (HY000): The slave is connecting using CHANGE MASTER TO
