sql - 使用 IN 与 = 运算符时在非主键列上使用聚簇索引

Question

如果我的 Product 表有一个 CategoryId 列，我知道将 CategoryId 设为聚集索引而不是主键 ProductId 是一个很好的做法。

如果我对 Product 表的大部分查询看起来像 select * from Product where CategoryId in (1, 2) 而不是更典型的 select * from Product，这是否仍然适用其中 CategoryId = 1

Answer 1

请非常小心选择您的聚簇索引!它非常特别——每个表只能有一个，它决定了数据的物理顺序，它用于唯一标识数据页的位置(“行指针”，如果你愿意的话)。

另外，它是 SQL Server 数据库中复制次数最多的数据结构(假设您正在谈论的是 SQL Server)。聚簇键也将成为表中每个非聚簇索引的一部分 - 当然在叶级别，也可能在索引导航结构中。

在选择集群键时应该格外小心——它应该是:

• narrow(4 字节理想)

• unique(毕竟它是“行指针”——如果你不让它唯一，SQL Server 会——为你——在后台——花费你几个字节对于每个条目 - 乘以行数和您拥有的非聚集索引的数量 - 可能非常昂贵!)

• 静态(永远不要改变 - 如果可能的话)

• 理想情况下不断增加，这样您就不会以可怕的索引碎片告终(GUID 与良好的集群键完全相反 - 出于这个特定原因)

• 它应该是不可为 null 的，理想情况下也可以固定为 - varchar(250) 会产生非常差的集群键

在这些点之后，其他任何事情都应该排在第二和第三位....

请参阅 Kimberly Tripp(索引女王)关于该主题的一些博客文章 - 她在博客中写的任何内容都绝对是无价的 - 阅读、消化它 - 以此为生!

• GUIDs as PRIMARY KEYs and/or the clustering key
• The Clustered Index Debate Continues...
• Ever-increasing clustering key - the Clustered Index Debate..........again!

在您的特定情况下，在 Products 表中选择 CategoryId 听起来不是一个好主意。产品的类别可能会改变，它很可能不是唯一的，因此我认为它不会真正成为如此好的聚类键。

此外，产品的类别听起来也不是很有选择性 - 因此它甚至可能不是一个好的非聚集索引。如果特定查询返回的行数超过总行数的 1-5%，则 SQL 查询优化器无论如何都不会使用大多数索引(因为它们返回的数据太多)。