mysqldump 备份时没加 --single-transaction
导致数据不一致
在可重复读（RR）隔离级别下，
mysqldump默认不开启事务快照，尤其对非 InnoDB 表（如 MyISAM）或混合引擎库，备份过程中表被写入就会产生逻辑不一致。InnoDB 表虽支持一致性备份，但必须显式加
--single-transaction才能获得全库级时间点一致视图。 不加该参数时，
mysqldump会逐表 dump，中间若有 DML，恢复后主从校验或业务核对容易发现主键冲突、记录缺失 若库中含 MyISAM 表，
--single-transaction无效，必须配合
--lock-all-tables（锁全库）或停写，否则必然不一致 注意：该参数要求服务器未启用
read_only=ON且用户有
RELOAD权限，否则会报错
Access denied; you need (at least one of) the RELOAD privilege(s)
恢复时用 source
执行大 SQL 文件卡住或中断
MySQL 客户端默认启用自动提交且无超时控制，导入超大 dump 文件（如 >1GB）时，单条语句执行太久可能触发网络中断、客户端断连，或因临时表空间不足直接失败；更隐蔽的问题是，
source不做语法预检，遇到注释格式异常、字符集不匹配的
SET NAMES就静默跳过，后续插入乱码却难以定位。 优先用命令行管道导入：
mysql -u user -p db_name ，避免客户端层干扰导入前确认目标实例
max_allowed_packet≥ dump 文件最大单行长度（可用
head -20 backup.sql | grep "INSERT INTO" | wc -L估算） 对含大量
INSERT的文件，建议先执行
SET unique_checks=0; SET foreign_key_checks=0;，导入完成再开回，提速且避错
备份文件没校验就删源库，恢复时发现编码/SQL 模式不兼容
MySQL 版本升级（如 5.7 → 8.0）后，
sql_mode默认值变化（如移除
NO_AUTO_CREATE_USER），旧备份里带
CREATE USER语句会报错；同样，备份时用
utf8mb4_0900_as_cs排序规则，但恢复库只支持
utf8mb4_general_ci，
CREATE TABLE就会失败。 备份命令中显式指定兼容性参数：
mysqldump --set-gtid-purged=OFF --column-statistics=0 --default-character-set=utf8mb4恢复前先用
head -50 backup.sql查看头部的
SET语句，比对目标库的
sql_mode和
character_set_server务必对备份文件做哈希校验（如
sha256sum backup.sql），并保留至少一份离线副本，别依赖“刚备份完肯定没问题”
物理备份（xtrabackup）没测恢复流程就上线
xtrabackup的
--prepare阶段看似成功，不代表能真正启动 mysqld；常见坑是 redo log 应用不完整、ibdata1 文件权限错误、或恢复路径下残留旧
ib_logfile*导致启动报错
InnoDB: The log sequence number in ibdata files does not match...。 每次备份后，必须在测试环境走完完整流程：copy-back → chown mysql:mysql →
mysqld --defaults-file=... --skip-networking启动验证 不要跳过
--use-memory参数调优：
xtrabackup --prepare若内存不足，会反复刷磁盘，耗时剧增且易中断 8.0+ 版本需注意加密表空间处理——若原库启用了
innodb_encrypt_tables，备份时没传
--encrypt-key，恢复后无法加载表 实际运维中最容易忽略的是：备份脚本里写死的密码明文泄露、crontab 时间与数据库慢日志轮转冲突导致磁盘打满、以及恢复演练只跑通“能启动”，却不验证
SELECT COUNT(*)和主从延迟归零。这些点不写进 checklist，迟早出事。
