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的博客文章。
此功能似乎以检测和避免车队为中心。
优化是通过对试图插入的工作人员应用流量控制来减少严重的争用和护送来实现的。这个想法是基于每个调度程序的不公平插入互斥量，它可以帮助避免闩等待名单的建立和结果的护送。当用户使用选项 OPTIMIZE_FOR_SEQUENTIAL_KEY 选择加入每个索引时，然后我们对插入工作程序进行流量/流量控制。本质上，每个调度器使用不公平互斥锁（在优化开启的 HoBt 级别），流量控制将只允许每个调度器的一个 worker 进入竞争页面锁存器的插入代码路径，这样我们就可以减少车队并提高并发插入的可伸缩性。Pam Lahoud 在她的博客文章中提供了所有这些细节我在功能规范或设计文档中找不到任何指示对当前 B-Tree 算法进行更改的内容。考虑的其他解决方案（其中一个是利用您在问题中引用的反向键索引的优化形式）具有潜在的缺点，并且大多数都涉及对引擎的根本更改。将来可能会考虑这些其他解决方案，但该解决方案在没有从根本上改变引擎的情况下提供了显着的改进。
您不希望将其部署在您不希望或遇到最后一页插入争用的地方。