OPTIMIZE_FOR_SEQUENTIAL_KEY 的实施和禁忌症

Question

SQL Server 2019 CTP3.1引入了解决最后一页插入争用的优化。这采用名为的索引选项的形式OPTIMIZE_FOR_SEQUENTIAL_KEY。

有人认为这可能是Bw-Tree或Bz-Tree的改编。然而，这些依赖于可变大小的页面，而当前的存储引擎需要固定大小的页面。

优化是如何实现的？这种优化如何改变当前的 B 树算法？在什么情况下我会选择不部署此选项？

研究

反向密钥方法的专利。

我使用 DBCC PAGE 快速浏览了一下，比较了 2017 年与 2019 年和 2019 年在 int IDENTITY 列的唯一聚集索引上使用和不使用 OPTIMIZE_FOR_SEQUENTIAL_KEY 的情况。没有什么可以明显地解释这种新行为。这让我觉得它是一个算法的东西，而不是一个结构的东西，这是有道理的。

来自 MS的博客文章。

此功能似乎以检测和避免车队为中心。

Answer 1

优化是通过对试图插入的工作人员应用流量控制来实现的，以减少严重的争用和护送。这个想法基于每个调度程序不公平的插入互斥锁，它可以帮助避免闩锁等待列表的积累和因此导致的护送。当用户使用选项 OPTIMIZE_FOR_SEQUENTIAL_KEY 选择每个索引时，然后我们对插入工作程序进行流量/流量控制。本质上，对每个调度程序使用不公平互斥（在优化的 HoBt 级别），流控制将允许每个调度程序只允许一个工作人员进入争用页面闩锁的插入代码路径，以便我们可以减少护航并改进并发插入的可扩展性。Pam Lahoud 在她的博客文章中提供了所有这些细节我在功能规范或设计文档中找不到任何指示当前 B 树算法更改的内容。考虑过的其他解决方案（其中之一是利用您在问题中引用的优化形式的反向键索引）具有潜在的缺点，并且大多数将涉及对引擎的根本性更改。未来可能会考虑这些其他解决方案，但该解决方案提供了显着的改进，而无需从根本上改变发动机。

您不希望在您不期望或遇到最后一页插入争用的地方部署它。