mysqldump 加 --single-transaction
仍可能丢数据？
不是加了就万事大吉。该参数只对 InnoDB 表生效，且要求事务隔离级别为
REPEATABLE READ（MySQL 默认），但若备份过程中有长事务正在执行 DDL（如
ALTER TABLE），或其它连接显式执行
FLUSH TABLES WITH READ LOCK，
--single-transaction会静默失效，转为隐式加全局读锁——此时写入阻塞，但更危险的是：若备份中途被 kill，已 dump 的部分可能对应一个不一致的时间点。 务必在备份前检查是否有活跃长事务：
SELECT * FROM information_schema.INNODB_TRX WHERE TIME_TO_SEC(NOW() - trx_started) > 60;避免与
pt-online-schema-change或
gh-ost同时运行 用
--dump-date记录时间戳，配合
SHOW MASTER STATUS输出的
File/
Position一起保存，便于后续校验
使用 --master-data=2
时 binlog 位点不可靠？
这个选项会在 dump 文件开头插入
CHANGE MASTER TO语句，但它的位点取自执行
FLUSH TABLES WITH READ LOCK之后、实际 dump 开始之前——中间存在微小时间窗口，若此时主库有新事务提交，该位点就“跳过”了这些事务，导致从库重放时数据不全。 生产环境建议改用
--source-data=2（MySQL 8.0.26+），它基于
START TRANSACTION WITH CONSISTENT SNAPSHOT获取位点，更精准 若必须用
--master-data=2，需搭配
--flush-logs，强制切换 binlog，让位点更靠近 dump 起始点 dump 完成后立即执行
SHOW BINLOG EVENTS IN 'xxx' FROM yyy LIMIT 1，确认第一个事件是否与 dump 中记录的位点一致
压缩备份文件导致校验失败？
mysqldump | gzip > backup.sql.gz看似省空间，但 gzip 过程中若管道中断（如磁盘满、OOM killer 杀掉进程），
backup.sql.gz可能是截断的，而
gzip -t只能验证压缩格式，无法保证 SQL 内容完整——解压后导入可能卡在半途或报语法错误。 先生成明文：
mysqldump ... > backup.sql再独立校验：
tail -n 20 backup.sql | grep -q "Dump completed"（确认结束标记存在） 最后压缩：
gzip backup.sql，并保留
md5sum backup.sql.gz哈希值用于恢复前比对 关键库建议额外生成逻辑校验：
mysqldump --no-data --skip-triggers ... | md5sum，对比结构一致性
备份用户权限不足引发静默截断？
如果备份账号缺少
SELECT权限，
mysqldump不会报错退出，而是跳过该表，只输出警告到 stderr（常被重定向忽略）。结果是 dump 文件里少了表，但看起来“成功”了。 备份前显式检查权限：
SHOW GRANTS FOR 'backup_user'@'%';确保包含
SELECT, LOCK TABLES, RELOAD, PROCESS, SHOW VIEW运行时捕获 stderr：
mysqldump ... 2> backup.err，结束后检查
grep -i "warning\|error" backup.err对含视图/存储过程的库，还需
SHOW VIEW和
EXECUTE权限，否则 dump 出的定义为空或报错
备份真正难的不是命令怎么写，是判断「此刻能不能安全备份」——比如主从延迟突增时，
--master-data记录的位点可能已经落后于从库实际回放位置，这种时间差不会报错，但会让备份失去可恢复性。
