恢复前必须停写或锁表，否则备份与恢复之间会产生不一致
MySQL 的逻辑备份（如
mysqldump）默认不保证全库强一致性，除非显式加锁或启用事务一致性选项。如果备份过程中有 DML 持续写入，恢复后很可能出现主从延迟、外键冲突、甚至部分表是“昨天的状态”，而另一些表是“今天的中间态”。
实操建议：
生产环境优先使用mysqldump --single-transaction --routines --triggers --databases，前提是所有表都是 InnoDB；
--single-transaction依赖 MVCC 快照，能避免全局锁，但仅对事务型引擎有效 若含 MyISAM 表，必须用
--lock-all-tables（会阻塞所有写），或临时切换为只读：
SET GLOBAL read_only = ON;，恢复完再关 跳过
--master-data或
--dump-slave时，别指望恢复后能直接对接原主从位点——binlog position 信息没被记录，主从重连需手动找点
用 mysqlpump
或 mydumper
替代老旧 mysqldump
可提升并发与一致性控制粒度
mysqldump是单线程、全库一把锁（哪怕加了
--single-transaction，DDL 仍可能破坏快照），而
mysqlpump（MySQL 5.7+）和
mydumper（第三方）支持按库/表并发导出，并可为每个表单独开事务快照。
关键差异：
mysqlpump --set-gtid-purged=OFF --single-transaction：比
mysqldump更细粒度地隔离事务快照，且默认跳过 performance_schema 等系统库
mydumper -t 4 --trx-consistency-only：用
--trx-consistency-only可跳过全局 FLUSH TABLES WITH READ LOCK，仅靠事务快照保障一致性，适合不能锁库的场景 二者均不兼容 MySQL 5.6 及更早版本，升级前先确认客户端和服务端版本匹配
物理备份（xtrabackup
）恢复时，--apply-log
和 --copy-back
顺序不能颠倒
Percona XtraBackup 的恢复分两步：先合并 redo log（
--apply-log），再拷回数据目录（
--copy-back）。跳过第一步直接拷贝，InnoDB 数据文件处于“崩溃状态”，MySQL 启动会失败并报错
InnoDB: Database page corruption on disk或卡在 crash recovery。
典型流程：
停止 MySQL：systemctl stop mysqld清空目标 datadir（如
/var/lib/mysql），否则
--copy-back会报错或覆盖不全 执行
xtrabackup --apply-log /path/to/backup（必须指定备份路径，且该路径下要有
xtrabackup_checkpoints） 再执行
xtrabackup --copy-back --target-dir=/path/to/backup，注意不是
--datadir改权限：
chown -R mysql:mysql /var/lib/mysql，否则启动报
Can't start server : Bind on unix socket...
恢复后必须校验，不能只看“Query OK”就认为成功
即使 SQL 执行无报错，也可能因字符集不匹配、SQL_MODE 差异、或视图/存储过程定义失效导致逻辑错误。例如：备份时
sql_mode='STRICT_TRANS_TABLES'，恢复库却是空 mode，INSERT 被静默截断；或
mysqldump导出的视图依赖某张已删表，恢复后
SHOW CREATE VIEW报错但不影响导入流程。
最小可行校验项：
对比行数：SELECT COUNT(*) FROM tbl_name在备份前后执行（注意大表加
SQL_NO_CACHE防缓存干扰） 查关键时间字段极值：
SELECT MIN(created_at), MAX(created_at) FROM orders，确认没丢最近/最早数据 运行
mysqlcheck --all-databases --check，检测表结构损坏（尤其 MyISAM 表） 如果有 GTID，检查
SELECT @@gtid_executed是否与备份时记录一致（若用了
--set-gtid-purged=ON）
一致性不是备份命令加个参数就自动达成的，它取决于你锁了什么、引擎是什么、恢复后有没有人立刻写入、以及是否真去看了数据而不是只看返回码。
