当表具有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（我猜它比行位置宽，但我不确定），那么索引创建可能会变慢。