Question

我有一个包含两个非常重要的字段的表：

id INT identity(1,1) PRIMARY KEY
identifiersortcode VARCHAR(900)

我的应用总是根据identifiersortcode在用户界面中对搜索结果进行排序和分页，但所有表连接（以及它们都属于军团）都在id字段上。 （旁白：是的，排序代码真的很长。有一个强大的BL原因。）

此外，由于使用O / RM，大多数SELECT语句几乎都会引入每一列。

目前，聚集索引位于id，但我想知道大多数查询的TOP / ORDER BY部分是否会使identifiersortcode成为集群密钥更具吸引力的选项，即使考虑到所有该表正在加入。

在表上插入，对identifiersortcode的更改有限，因此更改聚簇索引会成为插入/更新操作的问题。

尝试使排序代码的非聚集索引成为覆盖索引（使用INCLUDE）不是一个好的选择。有许多大型列，其中一些列有很多更新活动。

Answer 1

基于此，我会坚持使用您的整数标识id列，它满足以上所有要求。您的identifiersortcode将失去大部分（如果不是全部）这些要求。

Answer 2

要正确确定哪个字段将从聚簇索引中获益最多，您需要做一些功课。您应该考虑的第一件事是连接的选择性。如果你的执行计划从这个表FIRST过滤行，然后加入其他表，那么你并没有真正受益于主键上的聚集索引，并且将它放在排序键上更有意义。

但是，如果您的联接对其他表有选择性（它们被过滤，则执行索引查找以从该表中选择行），然后您需要手动比较更改的性能与现状。

Answer 3

为了上帝的缘故，为什么您的标识符排序代码需要长达900个字符？如果你真的需要900个字符来进行排序，那么它应该分成多个字段。

Answer 4

Appart重复Chris B.所说的话，我认为你应该坚持你现在的PK，因为 - 如你所说 - 所有联接都在Id上。
我猜你已经索引了identifierortcode .... 然而，如果你遇到性能问题，请重新考虑一下@＃“％$£identifiersortcode！ - ）

Answer 5

目前，聚集索引是id，但是我想知道大多数查询的TOP / ORDER BY部分是否会使identifierortcode成为一个更有吸引力的选项作为聚簇键，即使考虑到所有的表连接都在进行。 / p>

将identifiersortcode设为CLUSTERED KEY只有在过滤和排序条件中同时使用时才有用。

这意味着它在所有联接中被选为主要表，并使用Clustered Index Scan或Clustered Index Range Scan访问路径。

否则，它只会使事情变得更糟：首先，所有二级索引的规模都会更大;第二，以非递增顺序插入将导致页面拆分，这将使它们运行更长并导致更大的表。