mysql逻辑备份需停写或锁表以保证一致性，否则恢复后数据可能不一致；推荐使用–single-transaction（仅innodb）或–lock-all-tables（含myisam），物理备份xtrabackup须严格按–apply-log再–copy-back顺序执行。
恢复前必须停写或锁表，否则备份与恢复之间会产生不一致
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）
一致性不是备份命令加个参数就自动达成的，它取决于你锁了什么、引擎是什么、恢复后有没有人立刻写入、以及是否真去看了数据而不是只看返回码。