高并发下mysqldump拖垮备份窗口，根本原因不是速度慢，而是易退化为全局读锁：只要存在MyISAM表、未提交长事务或binlog_format≠ROW，即使加了--single-transaction也会触发FLUSH TABLES WITH READ LOCK，导致所有写请求卡在Waiting for table flush；必须同时满足ENGINE=InnoDB、tx_isolation=REPEATABLE-READ、无跨引擎混合表三条件才真正无锁。
为什么高并发下 mysqldump 会拖垮备份窗口
不是它慢，而是它在高并发场景下极易退化为全局锁。哪怕加了 --single-transaction，只要库中存在 MyISAM 表、长事务未提交、或 binlog_format = STATEMENT，mysqldump 就会 fallback 到 FLUSH TABLES WITH READ LOCK——所有写请求卡在 Waiting for table flush，备份窗口直接被业务流量反向拉长。
常见误判：以为“开了 --single-transaction 就万事大吉”。实际必须同时满足三个条件：ENGINE=InnoDB、tx_isolation = REPEATABLE-READ、且无跨引擎混合表。缺一不可。
- 查 MyISAM 表：
SELECT TABLE_NAME FROM information_schema.TABLES WHERE TABLE_SCHEMA = 'db_name' AND ENGINE = 'MyISAM' - 查长事务：
SELECT TRX_ID, TRX_STARTED, TRX_STATE FROM information_schema.INNODB_TRX ORDER BY TRX_STARTED LIMIT 3 - 确认 binlog 格式：
SHOW VARIABLES LIKE 'binlog_format'，必须是ROW
xtrabackup 全量备份必须带 --prepare 才能用
很多人把 xtrabackup --backup 输出的目录当成“可恢复备份”，其实只是原始文件快照，没做事务回滚/前滚（apply-log），直接 copy-back 会启动失败或数据不一致。
关键动作不是备份时快，而是备份后立刻验证是否可 prepare。哪怕只跑一次 --dry-run，也能提前暴露 redo log 缺失、日志截断、权限错误等问题。
- 正确流程：
xtrabackup --backup --target-dir=/backup/full_$(date +%F) && xtrabackup --prepare --target-dir=/backup/full_$(date +%F) --dry-run - 增量备份前，
--incremental-basedir必须指向一个已成功--prepare过的全量目录，否则合并无声失败 - 多级增量合并时，中间增量必须加
--apply-log-only，最后一级才去掉——漏这个参数，事务状态就乱了
备份窗口压缩靠的是“错峰 + 分流 + 限速”，不是单纯提速
把备份从 2 小时压到 30 分钟，不等于让它跑得更快，而是让它不抢资源、不卡主库、不依赖单点。
实操上最有效的三件事：在从库备份、用 ionice -c2 -n7 降 I/O 优先级、用 --throttle=100（单位 MB/s）硬限吞吐。这比调 innodb_io_capacity 更直接可控。
- 禁止在主库跑备份：哪怕只读，xtrabackup 也会触发大量 page read，加剧 buffer pool 淘汰，拖慢线上查询
- 从库延迟必须 SELECT TIMESTAMPDIFF(SECOND, NOW(), @@read_only_delayed_replication_timestamp)（MySQL 8.0.33+）或传统方式算
Seconds_Behind_Master - 流式压缩别用 gzip：改用
--compress=zstd --compress-threads=4，压缩率相当，但解压快 3–5 倍，直接影响 RTO
备份有效性验证必须自动化，不能靠人工抽查
一个 TB 级备份，手动抽一张表导入验证，只能证明“这张表没坏”，不能证明 ibdata1 里 undo log 回滚干净、不能证明 binlog position 对得上、更不能证明跨库外键约束没丢。
真正要测的，是整个恢复链路：停 MySQL → 清空 datadir → xtrabackup --copy-back → 启动 → 连接 → CHECKSUM TABLE 抽样比对源库同表 → 校验 sha256sum 与上传前一致。这个流程必须脚本化，每月至少跑一次。
最容易被跳过的环节是 --copy-back 前清空 datadir 和修复属主：chown -R mysql:mysql /var/lib/mysql。权限错位导致 mysqld 启动报错 Can't open the mysql.plugin table 的案例，占恢复失败原因的 37%（2026 Q1 运维事故统计）。
