不加–single-transaction会导致备份数据不一致：InnoDB需该参数才能保证全库时间点一致性，MyISAM则必须–lock-all-tables或停写；恢复时source大文件易卡顿、中断或乱码，应改用mysql命令行管道导入。
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，迟早出事。