mysqldump的--single-transaction选项能否保证数据完整性？

MySQL官方文档提到：

--single-transaction
该选项会将事务隔离级别设置为REPEATABLE READ，并在导出数据前向服务器发送START TRANSACTION SQL语句。它仅对InnoDB等事务型表有效，因为此时它会导出START TRANSACTION执行时数据库的一致状态，且不会阻塞任何应用。

我的疑问在于，文档中提到隔离级别被设置为REPEATABLE READ，但这可能无法保证数据库状态的一致性。

例如，我们有Employee表、Hobby表，以及存储员工ID和爱好ID的EmployeeHobby表。

当我们使用--single-transaction（即REPEATABLE READ）导出数据库时，将该事务记为A。

事务A先导出Employee表，之后并发事务B向Employee表插入一名新员工，同时向Hobby和EmployeeHobby表添加相关爱好数据（这并不违反REPEATABLE READ，因为事务A后续不会再读取Employee表），随后事务A导出EmployeeHobby表和Hobby表。

最终，事务A导出的数据并不一致，因为EmployeeHobby表中包含了Employee表中不存在的员工ID。

导出的数据是损坏的，不是吗？

文档中提到的：

它会导出START TRANSACTION执行时数据库的一致状态

似乎无法通过设置为REPEATABLE READ事务来实现。

你的担忧源于对InnoDB事务一致性视图机制的误解。在REPEATABLE READ隔离级别下，InnoDB会在事务执行START TRANSACTION时创建一个一致性读视图，这个视图固定了事务能访问的数据版本——所有后续查询都会基于该视图返回结果，完全不受并发事务后续操作的影响。

对应到你的场景：

• 事务A启动瞬间，InnoDB生成的一致性视图包含了当时所有已提交事务的数据状态。
• 事务B后续插入的新员工、爱好及关联数据，属于事务A启动后才产生的新数据版本，在事务A的一致性视图中完全不可见。
• 因此事务A导出EmployeeHobby表时，只会读取到事务启动时已存在的关联记录，绝对不会出现包含Employee表中不存在的员工ID的情况。

这就是官方文档描述的“导出START TRANSACTION执行时数据库的一致状态”的实现逻辑——整个导出过程基于同一个固定快照，跨表的数据必然保持一致。

需要注意：该机制仅适用于InnoDB等支持事务的存储引擎。对于MyISAM这类非事务型表，--single-transaction无法保证一致性，此时需要使用--lock-tables这类锁表方式来完成导出。

内容的提问来源于stack exchange，提问作者Name Null