select_for_update 是否会看到另一个 select_for_update 事务在解除阻塞后添加的行？

Question

我想创建一个模型，其 ID 等于该模型的当前最大 ID 加一（如自动增量）。我正在考虑使用select_for_update 执行此操作，以确保当前最大 ID 没有竞争条件，如下所示：

with transaction.atomic():
    greatest_id = MyModel.objects.select_for_update().order_by('id').last().id
    MyModel.objects.create(id=greatest_id + 1)

但我想知道，如果两个进程尝试同时运行它，一旦第二个进程解除阻塞，它会看到第一个进程插入的新的最大 ID，还是仍会看到旧的最大 ID？

例如，假设当前最大的 ID 是 10。两个进程去创建一个新模型。第一个锁定 ID 10。然后第二个阻塞，因为 10 被锁定。第一个插入 11 并解锁 10。然后，第二个解除阻塞，现在它会看到第一个插入的 11 是最大的，还是仍然会看到 10，因为那是它阻塞的行？

在 select_for_update docs 中，它说：

通常，如果另一个事务已经在其中一个选定的行上获得了锁，则查询将阻塞，直到锁被释放。

因此，对于我的示例，我认为这意味着第二个进程将在解除阻塞并获得 11 后重新运行最大 ID 的查询。但我不确定我的解释是否正确。

注意：我使用 MySQL 作为数据库。

Answer 1

编辑：我对这个答案的理解是错误的，只是为了文档的缘故留下它，以防我想回到它。

经过一番调查，我相信这会按预期工作。

原因是为了这个调用：

MyModel.objects.select_for_update().order_by('id').last().id

Django 生成并针对 db 运行的 SQL 实际上是：

SELECT ... FROM MyModel ORDER BY id ASC FOR UPDATE;

（对last() 的调用仅在查询集已被评估后发生。）

意思是，查询在两次运行时都会扫描所有行。这意味着它第二次运行时，它将拾取新行并相应地返回。

我了解到这种现象被称为“幻读”，并且是可能的，因为我的数据库的隔离级别是REPEATABLE-READ。

---

@KevinChristopherHenry “问题是在释放锁后查询没有重新运行；行已经被选中”你确定它是这样工作的吗？为什么 READ COMMITTED 意味着释放锁后选择不运行？我认为隔离级别定义了查询在运行时看到的数据快照，而不是~何时~查询运行。在我看来，选择是在释放锁之前还是之后发生与隔离级别正交。而且根据定义，阻塞查询不是在解除阻塞之前不会选择行吗？

对于它的价值，我尝试通过在 shell 中打开两个到我的数据库的单独连接并发出一些查询来测试这一点。首先，我开始了一个事务，并获得了一个锁'select * from MyModel order by id for update'。然后，在第二个中，我做了同样的事情，导致选择被阻止。然后回到第一个，我插入了一个新行，并提交了事务。然后在第二个中，查询解除阻塞，并返回新行。这让我觉得我的假设是正确的。

附：我终于实际上阅读了您阅读的“不良结果”文档，并且我明白了您的观点-在该示例中，它似乎忽略了未预选的行，因此这表明我的第二个查询不会选择向上新行。但是我在shell中进行了测试，它确实做到了。现在我不知道该怎么做。

Answer 2

不，我认为这行不通。

首先，请注意，您绝对应该检查您正在使用的数据库的文档，因为 Django 文档中未包含数据库之间的许多细微差别。

使用PostgreSQL documentation 作为指导，问题在于，在默认的READ COMMITTED 隔离级别下，被阻止的查询将不会重新运行。当第一个事务提交时，被阻塞的事务将能够看到对该行的更改，但无法看到已添加的新行。

更新命令可能会看到不一致的快照：它可以看到并发更新命令对其尝试更新的同一行的影响，但看不到这些命令对数据库中其他行的影响.

所以10 将被返回。