MySQL：彻底解决幻读还是貌似无幻读？

2024-01-23 13:42:26

各位读者，大家好！

在最近一期技术博客中，我们探讨了 MySQL InnoDB 引擎的默认隔离级别——“可重复读”。我们了解到，尽管这种隔离级别声称可以避免幻读，但实际上，情况并非完全如此。那么，MySQL 是否真的彻底解决了幻读问题呢？还是说，它只是给了我们一个“貌似无幻读”的假象？

快照读：幻读的温床

首先，我们需要了解幻读现象是如何产生的。幻读通常发生在快照读操作中。什么是快照读？它是一种在读取数据时创建数据副本（即快照）的操作。在隔离级别为“可重复读”的系统中，快照读被广泛使用，因为它可以保证事务在执行期间看到的数据库状态与事务开始时保持一致。

然而，快照读存在一个固有缺陷：它无法看到其他事务在快照创建后对数据库所做的修改。这意味着，如果两个事务同时对同一行数据进行读取操作，并且第一个事务在创建快照后，第二个事务对该行数据进行了修改，那么第一个事务将看不到这些修改。这就是幻读现象产生的根源。

MySQL 的解决之道：MVCC 和间隙锁

为了解决幻读问题，MySQL InnoDB 引擎采用了两种机制：多版本并发控制 (MVCC) 和间隙锁。

MVCC 通过为每行数据维护多个版本来实现。当一个事务对一行数据进行修改时，InnoDB 不会覆盖原有数据，而是创建一个新的版本。这样，当其他事务读取该行数据时，它们可以看到该行的不同版本，具体取决于事务的隔离级别。

间隙锁则用于防止幻读现象的发生。当一个事务对一行数据进行写操作时，它将获取该行的行锁。同时，它还会获取该行前后相邻行的间隙锁。这样，其他事务在对这些相邻行进行写操作时，将被阻止，从而防止幻读的产生。

貌似无幻读，实则不然

通过上述机制，MySQL InnoDB 引擎在很大程度上避免了幻读现象的发生。但是，需要注意的是，它并非彻底解决了幻读问题。在某些特定情况下，幻读仍然可能发生。

例如，如果一个事务对一行数据进行了更新操作，但由于某些原因（如死锁或超时）导致回滚，那么其他事务在读取该行数据时仍然可以看到更新后的值。这是因为，虽然更新操作被回滚了，但 MVCC 创建的数据版本仍然存在。

此外，如果一个事务对一行数据进行了删除操作，但由于某些原因导致回滚，那么其他事务在读取该行数据时仍然可以看到该行数据。这是因为，删除操作并不会物理删除数据，而是将该行的删除标记设置为 true。其他事务在读取该行数据时，如果看到删除标记为 true，就会将该行数据视为已被删除。但是，如果删除操作被回滚，删除标记将被重置为 false，导致该行数据重新出现在其他事务的快照中。