Mysql数据库幻读问题举例详解

前言

我们来详细地聊一聊 MySQL InnoDB 中的“幻读”（Phantom Read）问题。这是一个在数据库事务隔离中非常核心且有时令人困惑的概念。

我会从定义、例子、原因以及解决方案几个方面来彻底讲清楚。

1. 什么是幻读？

官方定义：幻读指的是在一个事务内，相同的查询在不同时间执行，返回了不同数量的行。

这听起来和“不可重复读”很像，但它们有关键区别：

• 不可重复读 (Non-Repeatable Read)：侧重于同一行的数据内容被修改或删除。（例如：你第二次查询时，某行的薪水从10000变成了12000）。

• 幻读 (Phantom Read)：侧重于新的行被插入（或删除），导致结果集的行数发生了变化。（针对结果集的数量变化，例如：你第一次查询有10条记录，第二次查询却冒出了11条）。

简单比喻：

• 不可重复读：你碗里的一块红烧肉被别人咬了一口（数据内容变了）。

• 幻读：你正准备夹碗里最后一块红烧肉时，别人突然又往碗里加了一块新的肉（数据行数变了）。

2. 幻读发生的场景与例子

幻读发生的根本原因是：在“可重复读（REPEATABLE READ）”及以下隔离级别中，普通的一致性读（快照读）无法阻止其他事务插入新的、满足当前查询条件的数据。

我们来看一个经典的例子。

表结构：

CREATE TABLE `employee` (
  `id` int(11) NOT NULL AUTO_INCREMENT,
  `name` varchar(50) NOT NULL,
  `salary` int(11) DEFAULT NULL,
  PRIMARY KEY (`id`),
  KEY `idx_salary` (`salary`)
) ENGINE=InnoDB;

INSERT INTO `employee` (`name`, `salary`) VALUES
('Alice', 8000),
('Bob', 9000),
('Charlie', 10000);

时间线：

例子分析：

1. T2时刻：事务A第一次查询，得到2条记录。

2. T4时刻：事务A第二次普通查询（快照读）。由于InnoDB的MVCC（多版本并发控制）机制，它会读取事务开始时的数据快照，所以看不到事务B新插入的 David(9500)。此时还没有幻读。

3. T5时刻：关键点来了！事务A执行了一个UPDATE操作。UPDATE/DELETE/INSERT 这类写操作会使用“当前读”（Current Read），它会读取数据库中最新的、已提交的数据。因此，它看到了事务B插入的 David(9500) 这条记录，并将其薪水也更新为8888。

4. T6时刻：事务A再次查询。因为之前的UPDATE操作属于当前事务的修改，所以MVCC规则允许它看到自己的修改。于是，它神奇地看到了三条记录！幻读就在这一刻发生了。

这个例子展示了InnoDB中幻读最典型的特征：即使是在默认的RR隔离级别下，先快照读，再当前读进行写操作，可能会意外地影响新插入的行，从而导致数据不一致。

3. 解决方案：Next-Key Lock 锁机制

InnoDB引擎为了解决幻读问题，在“可重复读（REPEATABLE READ）”隔离级别下就引入了一种叫做 Next-Key Lock 的锁机制。它实际上是 记录锁（Record Lock） 和 间隙锁（Gap Lock） 的结合。

• 记录锁 (Record Lock)：锁住索引上的某一条具体记录。

• 间隙锁 (Gap Lock)：锁住索引记录之间的“间隙”，防止在这个间隙内插入新的数据。它是一个左开右开的区间 (a, b)。

• 临键锁 (Next-Key Lock)：是记录锁 + 间隙锁的结合。它锁住一条记录和它前面的间隙。它是一个左开右闭的区间 (a, b]。

如何解决幻读？

在上面的例子中，如果事务A在第一次查询时，就对 salary > 8000 这个条件加上了锁，那么事务B的插入操作就会被阻塞，从而杜绝幻读。

让我们重演时间线，但这次事务A加锁查询：

发生了什么？

当事务A执行 SELECT ... FOR UPDATE 时，InnoDB会为其加Next-Key Lock。假设 salary 上有二级索引 idx_salary，它可能会锁住以下区间：

• 锁住 (8000, 9000] 这个Next-Key Lock（锁住9000这条记录和它前面的间隙）。

• 锁住 (9000, 10000] 这个Next-Key Lock（锁住10000这条记录和它前面的间隙）。

• 锁住 (10000, +∞] 这个Next-Key Lock（锁住正无穷的上界）。

事务B试图插入 salary = 9500 的记录，这个值落在被事务A锁住的 (9000, 10000] 间隙内，因此插入操作会被阻塞，直到事务A提交释放锁。这样就彻底防止了幻读的发生。

总结与最佳实践

核心要点：MySQL InnoDB 在 RR 级别下已经通过 Next-Key Lock 很大程度上解决了幻读问题。但你需要清楚地知道，只有在你的查询语句确实需要加锁（例如使用了 FOR UPDATE）或者涉及写操作时，Next-Key Lock 才会生效。单纯的快照读是无法完全避免幻读的潜在影响的。

到此这篇关于Mysql数据库幻读问题的文章就介绍到这了,更多相关Mysql幻读详解内容请搜索脚本之家以前的文章或继续浏览下面的相关文章希望大家以后多多支持脚本之家！

最新评论