当表具有PK时，为什么索引创建速度更快？ （SQL Server）

Question

我有一个实现SQL的表，它有600万条记录，仅用于SELECT操作。

我正在创建一个具有行号字段的PK，在某些情况下，创建此PK会花费5分钟以上的时间。为该字段（而非PK）创建索引所需的时间少于30秒。

[当我创建PK时，创建其他附加索引（与PK字段无关）的时间大约是我不创建PK（但为PK字段创建索引）的时间的1/3。

为什么这个时差？

Creating table (inserts): 262 sec
Creating index A (without PK constraint): 9 sec
Creating index C: 32 sec
Creating index D: 42 sec
Creating index E: 20 sec
Creating index F: 59 sec
Creating index G: 26 sec
Creating index H: 24 sec
Creating index I: 23 sec
Creating index J: 22 sec


Creating table (inserts): 135 sec
Creating index A (with PK constraint): 556 sec
Creating index C: 21 sec
Creating index D: 11 sec
Creating index E: 12 sec
Creating index F: 22 sec
Creating index G: 11 sec
Creating index H: 11 sec
Creating index I: 11 sec
Creating index J: 10 sec

其他索引来自单个字段，无论是文本还是日期。

分析这些情况，创建PK似乎更好（即使在SQL中不使用它，因为即使创建PK的速度要慢得多，如果创建更多的索引也会更快，但是我不明白为什么。

Answer 1

问题不是主键。事实上，主键是群集的（默认情况下）。速度的提高很可能是由于集群键（即主键）明显小于替代键（行定位符。]]的事实。

创建索引的许多工作都是在移动数据（按键排序并将结果保存在索引页上。）

documentation解释：

非聚集索引行中的行定位符是指向行或是行的聚集索引键，如以下：

• 如果表是堆，则表示它没有集群索引，行定位符是指向该行的指针。指针已建立从文件标识符（ID），页码和行号开始这一页。整个指针称为行ID（RID）。

• 如果表具有聚集索引，或者索引位于索引中视图，行定位符是该行的聚集索引键。

我猜想，速度增长最快的索引具有最小的键。相反，如果您的主键是GUID（我猜它比行位置宽，但我不确定），那么索引创建可能会更慢。