Percona XtraBackup 可实现 InnoDB 表不锁表热备，但 MyISAM 表全程加全局读锁；需确认全库为 InnoDB 引擎、启用 innodb_file_per_table、严格匹配版本并执行 --prepare 才能保证一致性恢复。
Percona XtraBackup 能否真正实现不锁表的热备
可以，但仅限于 InnoDB 表；MyISAM 表在备份全程会加全局读锁（FLUSH TABLES WITH READ LOCK），哪怕只有一张 MyISAM 表存在，整个备份过程就不是纯热备。
常见错误现象：应用写入明显卡顿、事务堆积、主从延迟突增——往往是因为误用了 --no-lock 参数，或没意识到系统库（如 mysql 库）里有 MyISAM 表（help_topic、plugin 等）。
- 必须确认所有业务表引擎为
InnoDB，用SELECT table_name, engine FROM information_schema.tables WHERE table_schema = 'your_db';检查 - 备份时默认仍会锁住非 InnoDB 表，如需跳过（不推荐生产环境），可加
--skip-locking，但要承担备份不一致风险 -
mysqld必须启用innodb_file_per_table = ON，否则xtrabackup无法单独拷贝单表空间
备份命令里最关键的三个参数怎么选
不是参数越多越安全，错配反而导致备份失败或恢复不可用。核心是搞清数据路径、权限和一致性保障方式。
-
--target-dir：必须是**空目录**，且xtrabackup进程对其有读写权限（不是 MySQL 用户权限）；不能指向datadir或其子目录 -
--user和--password：用于连接 MySQL 获取元数据（如gtid_executed、binlog 位置），账号只需RELOAD、PROCESS、SUPER、REPLICATION CLIENT权限，**不需要 FILE 权限**（旧文档常误写） -
--backup：这是执行备份动作的开关，漏掉它只会做准备不拷文件；而--prepare是后续恢复前的“回滚未提交事务+前滚已提交事务”步骤，两者不能混用
备份后不做 --prepare 直接恢复会怎样
大概率启动失败，报错类似 Tablespace is not found for table xxx 或 InnoDB: Database page corruption。因为 XtraBackup 备份的是“即时快照”，InnoDB 的 redo log 和数据页处于不同步状态，必须通过 --prepare 回放日志才能得到一致性数据文件。
- 单次全备恢复流程固定为三步：
xtrabackup --backup→xtrabackup --prepare→ 停库 + 替换datadir+ 启动 - 如果做了增量备份，
--prepare必须按顺序合并：先 prepare 全备（加--apply-log-only），再逐个 merge 增量（最后一个增量不加--apply-log-only） -
--prepare过程非常耗时且吃 CPU/IO，别在生产库上直接跑；建议在专用恢复机上完成
MySQL 8.0 下用 XtraBackup 8.0 备份时的兼容陷阱
版本必须严格对应：XtraBackup 8.0 只支持 MySQL 8.0.x（不含 8.1+），且要求 MySQL 开启 innodb_redo_log_encrypt = OFF（默认关闭，但如果手动开启过就会报错退出）。
- 备份时报
Unknown redo log format或Failed to read redo log header，大概率是 MySQL 版本超出了 XtraBackup 支持范围 - MySQL 8.0.30+ 默认启用
early_plugin_load = ""，若之前手动加载过加密插件，可能干扰 XtraBackup 初始化，需检查 error log 中是否出现Plugin 'keyring_file' is disabled类提示 - 备份生成的
xtrabackup_binlog_info文件里记录的是Executed_Gtid_Set，而非传统 file/pos，恢复时务必用SET GTID_PURGED导入，不能直接改CHANGE MASTER
真正麻烦的从来不是备份本身，而是你不知道哪张系统表还在用 MyISAM，或者哪台测试库悄悄启用了 redo 加密。备份脚本跑通不等于能恢复，--prepare 那一步永远别跳过。
