使用链表方法优化 SQL 中版本化记录的检索

Question

我有一个应用程序，它有一个大的版本记录表——也就是说，一条记录有一个在所有版本之间共享的 GUID（所以根本不是 GUID）和一个整数版本号。 GUID 和版本号一起是特定行的复合键。

业务逻辑表明，处理此表时最常见的操作是检索其中一条或多条记录的最新版本。现有代码以似乎效率最低的方式执行此操作 - 对于每条记录，它执行子查询以查找最大版本号，然后选择具有该版本号的记录。

伪代码：

currentRecord = record where record.ID == "{{guid}}"
    and record.versionNumber == 
        MAX(record.versionNumber where record.ID == "{guid}")

我真的很想对此进行优化，但我对 SQL 缺乏经验，我不知道该怎么做。比我更聪明的人已经尝试在这种设计的约束下进行优化，例如已经有我们可以创建的所有索引。是的，这种操作的低效率是一个重大问题，最终会影响我们的用户。

到目前为止，我有一个想法，我打算在有时间的时候尝试一下，类似于链表。除了版本号（仍然需要向用户显示）我想添加一个 true GUID versionID，然后每当我们创建记录的新版本时，我们都会指向一个previousVersion 列在上一个版本，并更新上一个版本的nextVersion 列指向新插入的行。这将允许将最新版本的检索简化为

currentRecord = record where record.ID == "{{guid}}"
    and record.NextVersion = NULL

这是个好主意吗？从我公认的有限理解来看，它应该将此操作从 O(N^2) 改进到 O(N)，对吧？它不会以任何方式改变我们想要记录的所有版本的情况。检索比插入更常见得多，因此它需要插入和更新来添加记录而不是仅仅插入这一事实不应该有任何明显的影响。

注意：有a question already from someone with the same problem，以及其他几个类似的方法，但没有人建议这种链表样式的方法——但他们确实提出了一种最终允许相同的空检查找到最新版本的方法，但是它使用了开始和结束日期，这在我的特定问题空间中会令人困惑（记录已经有开始和结束日期，含义完全不同）。我怀疑如果这是一个好主意，有人会在回答另一个问题时提出它，但这个想法让我很烦，所以我仍然希望有人解释它为什么很糟糕。

如果相关，我正在使用 SQL Server。

Answer 1

你的方法应该没问题。你只需要(id, recordNumber) 的索引。您可以在数据库中执行此操作：

create index t_id_recordNumber on t(id, recordNumber);

您的代码应自动使用此索引。

Answer 2

我尝试了它的工作/执行方式，并认为我会尽我所能回答我自己的问题。

我的测试代码可以在http://rextester.com/GKGJX28620 查看，但是在这种情况下它有点没有意义，因为这个站点不显示执行计划/统计信息。如果您足够好奇，您可能必须在 SSMS 或其他任何方式中运行它

到目前为止，我已经创建了两个测试。首先，我尝试通过其记录 ID（在所有版本之间共享）检索特定记录的最新版本。虽然在大多数情况下，旧方法和新方法都会导致完全相同的查询（单个索引查找）并花费相同的时间返回，但其他时候旧方法（使用子查询）会执行两次索引查找和相反，流聚合，最终会明显变慢。

在第二个测试中，我尝试在非键列上检索多条记录。我观察到新方法始终明显更快。它总是一个单一的索引查找，而旧的方法总是两个（加上一个流聚合）。每次这两个查询在同一个批次中运行时，旧方法占总执行时间的 71%，新方法占 29%。

总的来说，这似乎表明这个想法有一些优点，但我完全没有资格从事 SQL 优化，所以我很高兴有人有资格参与进来，解释一下我在这里搞砸了。