公认的答案主要表明，两者之间所谓的区别实际上根本不重要。

如果“一行被检索了两次，并且行中的值在读取之间不同”，那么它们不是同一行(在正确的RDB说法中不是同一个元组)，那么根据定义也确实是“第二个查询返回的行集合与第一个查询不同”的情况。

至于“应该使用哪个隔离级别”这个问题，您的数据对某人、某个地方越重要，Serializable就越有可能是惟一合理的选择。

我认为非重复读取和幻影读取之间有一些区别。

不可重复是指有两个事务A和B，如果B能注意到A的修改，那么可能会发生脏读，所以我们让B在A提交后注意到A的修改。

有一个新的问题:我们让B在A提交后注意到A的修改，这意味着A修改了B所持有的行的值，有时B会再次读取该行，因此B将获得与我们第一次获得的不同的新值，我们称之为不可重复的，为了解决这个问题，我们让B在B启动时记住一些东西(因为我还不知道会记住什么)。

让我们考虑一下新的解决方案，我们可以注意到也有新的问题，因为我们让B记住了一些东西，所以不管A发生了什么，B都不会受到影响，但是如果B想要向表中插入一些数据，B检查表，确保没有记录，但是这个数据已经被A插入，所以可能会发生一些错误。我们称之为幻读。

读现象

脏读:从另一个事务读取未提交的数据 不可重复读取:从另一个事务的UPDATE查询中读取COMMITTED数据 幻影读取:从另一个事务的INSERT或DELETE查询中读取COMMITTED数据

注意:来自另一个事务的DELETE语句，在某些情况下也有非常低的概率导致不可重复读取。不幸的是，当DELETE语句删除当前事务正在查询的同一行时，就会发生这种情况。但这种情况很少见，在每个表中都有数百万行的数据库中更不可能出现这种情况。在任何生产环境中，包含事务数据的表通常都有很大的数据量。

此外，我们还可以观察到，在大多数用例中，更新作业可能比实际的INSERT或delete作业更频繁(在这种情况下，仅存在不可重复读取的危险-在这些情况下不可能出现幻影读取)。这就是为什么update与INSERT-DELETE处理方式不同，导致的异常命名也不同。

处理insert - delete(而不仅仅是处理update)还需要额外的处理成本。

不同隔离级别的好处

READ_UNCOMMITTED什么也阻止不了。这是零 隔离级别 READ_COMMITTED只阻止一种，即脏读 REPEATABLE_READ防止两种异常:脏读和 不可重复读 SERIALIZABLE可以防止所有三种异常:脏读， 不可重复读取和幻影读取

那么为什么不始终设置事务SERIALIZABLE呢?好吧，上述问题的答案是:SERIALIZABLE设置使事务非常慢，这也是我们不希望看到的。

实际上，事务时间消耗的速率如下:

Serializable > repeatable_read > read_committed > read_uncommitted

所以READ_UNCOMMITTED设置是最快的。

总结

实际上，我们需要分析用例并确定隔离级别，以便优化事务时间并防止大多数异常。

注意，数据库在默认情况下可能有REPEATABLE_READ设置。管理员和架构师可能倾向于将此设置作为默认设置，以展示更好的平台性能。

不可重复读是一个隔离级别，幻影读(通过其他事务读取已提交的值)是一个概念(读的类型，例如脏读或快照读)。不可重复读隔离级别允许幻影读，但不允许脏读或快照读。

公认的答案主要表明，两者之间所谓的区别实际上根本不重要。

如果“一行被检索了两次，并且行中的值在读取之间不同”，那么它们不是同一行(在正确的RDB说法中不是同一个元组)，那么根据定义也确实是“第二个查询返回的行集合与第一个查询不同”的情况。

至于“应该使用哪个隔离级别”这个问题，您的数据对某人、某个地方越重要，Serializable就越有可能是惟一合理的选择。

这两种隔离级别之间的实现存在差异。 对于“不可重复读”，需要行锁定。 对于“幻影读取”，需要范围锁定，甚至是表锁定。 我们可以使用两相锁协议来实现这两个级别。