mysql如何防止不可重复读

P粉602998670

发布时间：2025-09-30 17:06:02

741人浏览过

来源于php中文网

原创

MySQL在REPEATABLE READ下通过MVCC防止不可重复读，事务基于快照读数据，确保一致性；但使用SELECT ... FOR UPDATE或降低隔离级别至READ COMMITTED时需注意数据可见性变化，显式加锁会读最新数据，可能破坏重复读；此外DDL操作也可能影响事务视图。应对策略包括显式加锁、应用层缓存或重构事务逻辑，优先推荐保持默认隔离级别以利用MVCC优势。

mysql如何防止不可重复读

MySQL在默认的REPEATABLE READ隔离级别下，通过其多版本并发控制（MVCC）机制，已经很好地防止了不可重复读的问题。这意味着，在一个事务内部，即使其他事务修改了数据，你再次读取同一行，看到的数据版本依然是你事务开始时的那个版本，保持了数据的一致性视图。

核心在于MVCC。当一个事务启动时，MySQL会为它创建一个“快照”或者说一个“读视图”。所有在该事务中进行的普通SELECT查询，都会基于这个快照来读取数据。如果其他事务在此期间修改了数据，对当前事务来说是不可见的，因为它只能看到快照创建时的数据版本。这种机制确保了在事务的整个生命周期内，对同一行的多次读取都返回相同的结果，从而有效地避免了不可重复读。

既然MySQL默认就防，那还有什么情况需要注意？

这确实是个好问题，因为“默认”不代表“万无一失”或者“可以随意操作”。在我看来，虽然REPEATABLE READ配合MVCC已经很强大了，但有几个场景还是值得我们留意的。

显式加锁的SELECT语句： 如果你使用了SELECT ... FOR UPDATE或者SELECT ... LOCK IN SHARE MODE，这些语句会绕过MVCC的快照读机制，直接读取最新的数据并加锁。在这种情况下，如果你在一个事务里先普通SELECT，再SELECT ... FOR UPDATE同一行，可能会看到不同的数据。
- 例子： 假设账户ID为1的余额是100。
  - 事务A：START TRANSACTION;
  - 事务A：SELECT balance FROM accounts WHERE id = 1; (结果是100)
  - 事务B：START TRANSACTION; UPDATE accounts SET balance = 200 WHERE id = 1; COMMIT;
  - 事务A：SELECT balance FROM accounts WHERE id = 1 FOR UPDATE; (此时，事务A可能会读取到200，因为它需要获取最新的数据并加锁，这与第一次的快照读结果不同。)
- 思考： 这不是不可重复读的“坏处”，而是显式加锁的“目的”——为了获取最新数据并锁定，以进行后续的更新操作。但如果你的业务逻辑不清楚这一点，可能会产生误解，以为是不可重复读。
更改隔离级别： 如果你因为某些性能考量或者兼容性需求，将事务隔离级别设置成了READ COMMITTED（比如SQL Server和Oracle的默认级别），那么不可重复读就会立刻浮现。在READ COMMITTED下，每次SELECT都会读取最新的已提交数据，所以同一事务内的两次查询可能会看到不同结果。
- 个人建议： 除非你非常清楚你在做什么，并且已经有完善的应对策略，否则不要轻易将MySQL的隔离级别从REPEATABLE READ降到READ COMMITTED。
DDL操作的影响： 虽然不常见，但某些DDL操作（如ALTER TABLE）可能会隐式地提交事务，或者对表的结构进行修改，这在极端情况下也可能影响到正在进行的事务的数据视图。不过这通常不是我们讨论不可重复读时的核心点，更多是数据库操作的原子性问题。

MVCC在REPEATABLE READ级别下是如何工作的？

要理解为什么MySQL能防止不可重复读，深入了解MVCC（Multi-Version Concurrency Control，多版本并发控制）是绕不开的。这玩意儿听起来有点玄乎，但其实核心思想并不复杂。

简单来说，MVCC就是通过保存数据行的多个版本，来让并发事务看到“各自”的数据视图。在REPEATABLE READ级别下，当一个事务启动时，它会获得一个唯一的事务ID（transaction_id），并且会记录下当前活跃的事务列表。这个列表，连同事务ID，共同构成了一个“读视图”（Read View）。

读视图的作用： 这个读视图就像给当前事务拍了一张照片。之后，无论这个事务进行多少次SELECT查询，它都只会去读取那些在它“拍照”时已经存在，并且已经提交的数据版本。
数据行版本： 每当一行数据被修改时，MySQL（特指InnoDB存储引擎）并不会直接覆盖旧数据，而是会创建一个新版本的数据行，并把旧版本的数据放到undo log（回滚日志）里。每个数据行版本都会带有创建它的事务ID（trx_id）和删除它的事务ID（roll_pointer，指向undo log）。
判断可见性： 当一个事务要读取一行数据时，它会拿着自己的读视图去判断这个数据行的哪个版本是可见的。
- 如果数据行的trx_id小于当前事务的最小活跃事务ID（也就是在当前事务启动前就已经提交的），那这个版本就可见。
- 如果数据行的trx_id等于当前事务的ID，那也是可见的（自己修改的数据自己能看到）。
- 如果数据行的trx_id在当前事务的活跃事务列表里，说明这个数据是在当前事务启动后由其他活跃事务修改的，那就不可见，需要沿着undo log链条找更老的版本。
- 如果数据行的trx_id大于当前事务的最大活跃事务ID（也就是在当前事务启动后才启动的事务），那这个版本也是不可见的。

通过这种机制，一个事务在整个生命周期内，看到的都是它启动时的数据快照，从而有效地避免了不可重复读。即使其他事务在这期间修改并提交了数据，当前事务也“视而不见”，除非它自己也去修改同一行数据。

Flex3组件和框架的生命周期中文WORD版

在整本书中我们所涉及许多的Flex框架源码，但为了简洁，我们不总是显示所指的代码。当你阅读这本书时，要求你打开Flex Builder，或能够访问Flex3框架的源码，跟随着我们所讨论源码是怎么工作及为什么这样做。如果你跟着阅读源码，请注意，我们经常跳过功能或者具体的代码，以便我们可以对应当前的主题。这样能防止我们远离当前的主题，主要是讲解代码的微妙之处。这并不是说那些代码的作用不重要，而是那些代码处理特别的案例，防止潜在的错误或在生命周期的后面来处理，只是我们当前没有讨论它。有需要的朋友可以下载看看

下载

如果我真的需要更低的隔离级别，比如READ COMMITTED，又想避免不可重复读怎么办？

嗯，这是一个有点矛盾的需求，但现实中确实可能遇到。比如，你可能需要READ COMMITTED来减少锁冲突，或者因为应用程序设计习惯了这种行为。在这种情况下，我们不能指望数据库的默认隔离级别来解决不可重复读，就得自己想办法了。

坦白说，没有银弹。一旦你放弃了REPEATABLE READ的全局快照，你就得接受每次读都可能看到最新已提交数据的现实。但如果某些关键数据块你需要“重复读”一致性，可以考虑以下几种策略：

显式加锁： 这是最直接，也是最粗暴的方式。如果你知道某个SELECT操作的结果后续会被再次读取，并且需要保持一致，你可以直接使用SELECT ... FOR UPDATE或SELECT ... LOCK IN SHARE MODE。
- SELECT ... FOR UPDATE：会给选定的行加上排他锁（X锁），直到事务结束才释放。其他事务不能修改这些行，也不能加任何锁。
- SELECT ... LOCK IN SHARE MODE：会给选定的行加上共享锁（S锁）。其他事务可以读取这些行（也可以加S锁），但不能修改（不能加X锁）。
- 缺点： 显式加锁会增加锁竞争，降低并发性能。你必须非常清楚哪些数据需要加锁，加什么锁，以及锁的粒度。过度使用可能导致死锁。
应用层缓存： 在事务开始时，将需要保持一致性的数据读取出来，存储在应用程序的内存中（或者事务级别的缓存）。后续对这些数据的读取都从缓存中获取，而不是再次查询数据库。
- 优点： 避免了数据库层面的锁竞争，性能较好。
- 缺点： 增加了应用程序的复杂性，需要自己管理缓存的生命周期和一致性。如果数据量大，内存开销也需要考虑。这本质上是将数据库的“快照”功能搬到了应用层。
事务拆分与逻辑重构： 重新审视你的业务逻辑，看是否真的需要在同一个长事务中多次读取同一份数据。有时候，不可重复读的问题是因为事务粒度过大造成的。
- 思考： 能不能把一些只读操作提前，或者将修改操作封装成更小的事务？这需要对业务流程有深入的理解。
悲观锁与乐观锁的结合（针对更新场景）： 如果不可重复读导致的问题主要是后续更新基于旧数据，那么结合乐观锁（版本号或时间戳）或者在更新时再次确认数据状态（悲观锁思想）会更合适。但这已经超出了单纯防止不可重复读的范畴，更多是解决并发更新的问题。