会，但不是必然——取决于备份方式；mysqldump加全局读锁会导致写入阻塞，xtrabackup物理备份不锁InnoDB表，仅毫秒级FTWRL获取位点，不影响业务。
全量备份期间业务会卡顿甚至超时吗？
会，但不是必然——取决于备份方式。直接用 mysqldump 加全局读锁（FLUSH TABLES WITH READ LOCK）会导致写入阻塞，高并发下接口响应明显变慢，甚至触发超时；而 xtrabackup 的物理备份在大多数情况下不锁表，InnoDB 表全程可读可写。
关键区别在于：xtrabackup 通过拷贝 InnoDB 的数据文件 + redo log 实现一致性，它依赖的是 InnoDB 自身的崩溃恢复机制，而非 SQL 层锁。
- MyISAM 表仍会被锁（但现代业务基本不用 MyISAM）
- 备份开始时会有极短的 FTWRL（毫秒级），仅用于获取 binlog 位置和 LSN，不影响业务感知
- 如果备份过程中 redo log 生成过快（比如大事务持续提交），可能拉长 backup_log_copy 阶段，间接增加备份时间，但不阻塞 DML
xtrabackup 备份命令里哪些参数不能错？
三个核心参数一旦配错，轻则备份失败，重则恢复出错或丢失一致性：
-
--backup必须显式指定，漏掉就变成 prepare 或 copy-back 操作 -
--target-dir路径必须为空目录，否则报错already exists；且需保证磁盘空间 ≥ 数据目录大小 × 1.2（含 redo 日志增量） -
--user和--password要有RELOAD, PROCESS, LOCK TABLES, REPLICATION CLIENT权限，缺REPLICATION CLIENT会导致无法获取 binlog 位点，影响后续搭建从库
示例正确命令：
xtrabackup --backup --user=backup_user --password='xxx' --target-dir=/data/backup/20240520/
备份后不执行 --prepare 就恢复，会发生什么？
直接 copy-back 会启动失败，报错类似 InnoDB: Database page corruption on disk 或 innodb_page_size mismatch。
因为 xtrabackup 备份的是“运行中”的物理文件，包含未刷盘的脏页和未合并的 redo log，必须靠 --prepare 回放日志、前滚事务、清理未提交变更，才能得到一个一致的、可启动的状态。
- 线上建议分两步：先备份 → 再挪到离线机做
--prepare（避免占用生产 IO） -
--prepare过程不可中断，否则备份目录损坏，需重备 - 如需压缩备份，应在
--prepare后再 tar/gzip，而不是备份时加--compress（v8.0+ 已弃用该参数）
为什么备份速度忽快忽慢，有时还触发 OOM？
本质是 xtrabackup 对内存和 IO 的调度策略与 MySQL 实际负载冲突导致的。
- 默认使用 10 个 IO 线程（
--parallel=10），若磁盘 IOPS 不足，大量随机读会拖垮 MySQL 的 buffer pool 命中率，表现为 QPS 下降、慢查询激增 -
--throttle参数没设，xtrabackup 会尽可能吃满 IO，和业务抢资源 - 大表（>50GB）单次读取易触发 Linux page cache 淘汰，导致 mysqld 频繁重读索引页，内存压力陡增
建议操作：
xtrabackup --backup ... --parallel=4 --throttle=100 --rsync
其中
--throttle=100 表示每秒最多 100 次 IO 请求，可根据 iostat -dxm 1 观察 %util 控制在 70% 以下。
真正麻烦的是备份期间恰好遇到大事务回滚或长查询扫描，此时 xtrabackup 的 checkpoint 等待会延长，整个备份窗口不可控——这没法靠参数规避，得靠业务侧配合错峰。
