答案实际上取决于您如何查询数据.聚集索引优于所有其他索引：因为它始终包含所有列,所以总是覆盖.因此,可以利用聚簇索引的查询当然不需要使用查找来满足某些预计列和/或谓词.

另一个难题是如何使用索引？有三种典型模式：

>探测,在索引中搜索单个键值时
>范围扫描,检索一系列键值时
>按要求排序,当索引可以满足订单时不需要停止排序

因此,如果您分析预期的负载(查询)并发现大量查询将使用特定索引,因为它们使用某种受益于索引的访问模式,那么将该索引建议为聚簇索引是有意义的.

另一个因素是聚簇索引键是所有非聚簇索引使用的查找键,因此宽聚簇索引键会产生连锁反应并扩大所有非聚簇索引,宽索引意味着更多页面,更多I / O,更多的记忆,更少的善良.

良好的聚簇索引是稳定的,它在实体的生命周期内不会更改,因为聚簇索引键值的更改意味着必须删除并插入行.

并且良好的聚簇索引按顺序增长(不是每个新插入的键值大于前一个值),以避免页面拆分和碎片(不会弄乱FILLFACTOR).

那么现在我们知道一个好的聚簇索引键是什么,主键(它是一个数据建模逻辑属性)是否符合要求？如果是,那么PK应该是聚类的.如果不是,则PK应该是非群集的.

举个例子,考虑销售事实表.每个条目都有一个ID作为主键.但绝大多数查询都要求在日期和另一个日期之间提供数据,因此最佳聚簇索引键是销售日期,而不是ID.从主键获得不同聚簇索引的另一个例子是非常低的选择性键,如“类别”,或“状态”,只有很少的不同值的键.将具有该低选择性密钥的聚簇索引密钥作为最左侧的密钥,例如,(state,id),通常是有意义的,因为范围扫描会查找特定“状态”中的所有条目.

关于堆上非聚集主键的可能性的最后一个注释(即根本没有聚簇索引).这可能是一个有效的方案,典型的原因是批量插入性能至关重要,因为与聚簇索引相比,堆的批量插入吞吐量明显更好.