在问了这个比较顺序和非顺序 GUID 的问题后，我尝试比较 INSERT 性能在 1) 一个带有顺序初始化的 GUID 主键newsequentialid()的表，和 2) 一个带有顺序初始化的 INT 主键的表identity(1,1)。我希望后者最快，因为整数的宽度较小，并且生成顺序整数似乎比顺序 GUID 更简单。但令我惊讶的是，带有整数键的表上的 INSERT 比顺序 GUID 表慢得多。
这显示了测试运行的平均时间使用 (ms)：
NEWSEQUENTIALID() 1977
IDENTITY() 2223
谁能解释一下？
使用了以下实验：
SET NOCOUNT ON
CREATE TABLE TestGuid2 (Id UNIQUEIDENTIFIER NOT NULL DEFAULT NEWSEQUENTIALID() PRIMARY KEY,
SomeDate DATETIME, batchNumber BIGINT, FILLER CHAR(100))
CREATE TABLE TestInt (Id Int NOT NULL identity(1,1) PRIMARY KEY,
SomeDate DATETIME, batchNumber BIGINT, FILLER CHAR(100))
DECLARE @BatchCounter INT = 1
DECLARE @Numrows INT = 100000
WHILE …考虑一个总是单调增加的值的 B 树索引，例如 IDENTITY 类型的列。使用传统的 B 树实现，每当节点已满时，它将被拆分 50%/50%，我们最终得到一个 B 树，其中（几乎）所有节点都只有 50% 已满。
我知道 Oracle 会发现值何时不断增加，在这些情况下，Oracle 会执行 90%/10% 的拆分。这样，（几乎）所有节点都将充满 90%，并且对于这些非常常见的情况，可以获得更好的页面利用率。
我无法在 SQL Server 中找到类似功能的文档。但是，我进行了两次实验，分别在索引中插入了 N 个随机整数和 N 个连续整数。前一种情况使用了更多的页面，后者。
SQL Server 是否提供类似的功能？如果是这样：你能指点我一些关于这个功能的文档吗？
更新： 通过下面提供的实验，似乎叶节点保持未分裂，内部节点分裂 50%/50%。这使得增加键上的 B 树比随机键上的更紧凑。然而，Oracle 的 90%/10% 方法甚至更好，我仍然在寻找一些官方文档来验证实验中看到的行为。