如果我的Product表有一个CategoryId列，我理解将CategoryId作为聚簇索引而不是主键ProductId是一个好习惯。
如果针对Product表的大多数查询看起来像select * from Product where CategoryId in (1, 2)而不是更典型的select * from Product where CategoryId = 1
答案 0 :(得分：5)
请非常仔细选择您的聚集索引！它非常特殊 - 每个表只能有一个，它决定了数据的物理顺序，它用于唯一地标识数据页的位置（“行指针”，如果你愿意的话）。 / p>
此外，它是SQL Server数据库中最复制的数据结构（假设它是您正在讨论的SQL Server）。聚类键也将是表上每个非聚集索引的一部分 - 当然在叶级别，也可能在索引导航结构中。
选择群集密钥时应特别小心 - 它应该是：
缩小（4字节理想）
唯一（毕竟它是“行指针” - 如果你没有让它变得独一无二，那么SQL Server将 - 为你 - 在后台 - 花费几个字节对于每个条目 - 次数，行数和非聚集索引的数量 - 可能非常昂贵！）
静态（永不改变 - 如果可能的话）
理想情况下不断增加所以你不会最终得到可怕的索引碎片（GUID与一个好的聚类键完全相反 - 出于特殊原因）
它应该是不可为空的，理想情况下也是固定的 - varchar(250)制作非常差的群集密钥
其他任何事情都应该是这些要点背后的第二和第三层次的重要性......
查看Kimberly Tripp（索引女王）的一些博客文章 - 她在博客中写的任何内容都绝对无价 - 阅读，消化它 - 靠它生活！
在您的具体情况下，在CategoryId表格中选择Products听起来不是一个好主意。产品的类别可能会发生变化，它很可能不是唯一的，因此我认为它不会真正做出如此好的集群密钥。
此外，产品的类别听起来也不是很有选择性 - 因此它甚至可能不会产生良好的非聚集索引。如果特定查询返回超过总行数的1-5％，则SQL查询优化器将不会使用大多数索引（因为它们返回的数据太多）。