我的问题是,是否明智将PrimaryKey分配给ID列,而将ClusteredIndex分配给EmployeeNumber?
可以使用非聚集主键,并且可以有一个完全不相关的聚集键。默认情况下,主键也会成为聚集索引键,但这不是必须的。
主键是一个逻辑概念:用于引用实体的关键字。
聚集索引键是一个物理概念:用于在磁盘上存储行的顺序。
选择不同的聚集键是由各种因素驱动的,例如关键字宽度,当您希望聚集键比主键窄时(因为聚集键在每个非聚集索引中都被复制)。或者支持频繁的范围扫描(在时间序列中很常见),当数据经常使用查询访问,例如date between '20100101' and '20100201'
(在date
上的聚集索引键是适当的)。
这个主题已经在这里被反复讨论过,也可以参考What column should the clustered index be put on?。
理想的聚集索引键应该是:
一般来说,使用 GUID 作为聚集索引键是一个非常糟糕的想法,因为随着行的添加,它会导致大量的分片。
澄清编辑:
主键和聚集键确实是不同的概念。您的主键不需要成为聚集索引键。
在实际应用中,根据我的经验,与您的主键相同的字段应该/将成为聚集键,因为它符合上述相同的标准。
如果在非主键字段上使用聚集索引,将会提高SELECT查询的性能,因为它将利用此索引。
但是,在大多数情况下,UPDATE查询依赖于主键来查找要更新的特定行,因此您将失去性能。
CREATE查询也可能会失去性能,因为当您在索引中间添加新行时,必须移动许多其他行。如果使用自增的主键,则不会发生这种情况,因为新记录始终添加在末尾,不会移动任何其他行。
如果您不知道哪种操作需要最佳性能,则建议将聚集索引保留在主键上,并在常见搜索条件上使用非聚集索引。
聚集索引会导致数据按照特定顺序物理存储。因此,在测试连续行范围时,聚集索引非常有帮助。
GUID是非常糟糕的聚集索引,因为它们的顺序不符合有意义的排序模式。Int Identity列也不太好,除非输入顺序有帮助(例如,最近的雇用)。
由于您可能不会寻找员工范围,因此哪个是聚集索引可能并不重要,除非您可以分段处理经常不感兴趣的员工块(例如,终止日期)。
由于EmployeeNumber是唯一的,我会将其作为主键。在SQL Server中,PK通常是集群索引。
使用GUID进行连接非常糟糕。@JNK对此回答得很好。