mysqldump --single-transaction 自动启用 repeatable read 并 begin 获取一致性快照，仅对 innodb 有效；非 innodb 表需加锁；关键在事务起点而非隔离级别设置，务必显式指定该选项并避免 --skip-opt。
可重复读（REPEATABLE READ）隔离级别本身不能防止备份过程中数据被修改——它只保证事务内多次读取结果一致，不锁表、不阻塞写入，备份时仍可能产生不一致快照。
mysqldump 默认行为与隔离级别无关
mysqldump 默认使用 --single-transaction 选项时，会启动一个一致性快照事务，底层依赖的是 InnoDB 的 MVCC 快照机制，而非显式设置会话隔离级别。即使你手动执行 SET SESSION TRANSACTION ISOLATION LEVEL REPEATABLE READ，也不改变 mysqldump 的行为逻辑。
-
mysqldump --single-transaction自动开启 REPEATABLE READ 级别并执行BEGIN，这是它的内部实现，无需手动干预 - 如果备份期间有长事务未提交，
mysqldump的快照可能被拖住，导致备份变慢甚至失败（Waiting for table flush等待现象） - 非 InnoDB 表（如 MyISAM）不支持
--single-transaction，此时必须用--lock-all-tables或--lock-tables配合全局读锁
真正起作用的是 --single-transaction + 事务起点控制
关键不是“设了什么隔离级别”，而是 mysqldump 是否在备份开始前获取了一个确定的事务快照点（即 SHOW MASTER STATUS 或 SELECT @@GLOBAL.GTID_EXECUTED 对应的位点）。这个快照由 BEGIN 触发，且仅对 InnoDB 有效。
- 务必确认备份命令中明确包含
--single-transaction，否则默认是--lock-tables，会逐表加读锁，影响写入 - 搭配
--master-data=2可自动记录 binlog 位置，用于后续搭建从库或时间点恢复 - 避免在备份过程中执行
ALTER TABLE、DROP TABLE等隐式提交语句，它们会中断一致性事务 - 检查
innodb_lock_wait_timeout和wait_timeout，防止备份事务因超时被回滚
遇到数据不一致？先查是否误用了 --skip-opt
很多线上问题源于自定义 mysqldump 参数时错误禁用了关键选项。例如 --skip-opt 会默认关闭 --add-drop-table、--add-locks、--extended-insert，同时也隐式取消 --single-transaction 的自动启用。
- 不要用
--skip-opt，改用显式指定需要的选项，比如--no-autocommit --skip-triggers --compact - 检查实际执行的 dump 命令是否含
--single-transaction：运行ps aux | grep mysqldump或查看备份脚本 - 验证备份一致性：还原后比对某张大表的
COUNT(*)和主库是否一致；或用pt-table-checksum对比校验和
最易被忽略的一点：REPEATABLE READ 是会话级设置，而 mysqldump 的每个表导出都复用同一个连接，但快照起点只在第一个 BEGIN 时确定——这意味着整库备份的“一致性”完全取决于那个初始事务是否能覆盖所有表的读取时机，而不是靠反复设置隔离级别来维持。
