是，--single-transaction 并非绝对安全：仅对 InnoDB 有效，遇长事务 DDL 或 FLUSH TABLES WITH READ LOCK 会静默降级为全局读锁，kill 备份可能导致部分数据不一致。

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 记录的位点可能已经落后于从库实际回放位置，这种时间差不会报错，但会让备份失去可恢复性。