sql-server – 标识列上的索引是否应该是非聚簇的?
对于具有标识列的表,是否应为标识列创建集群或非集群PK /唯一索引?
原因是将为查询创建其他索引.使用非聚簇索引(在堆上)并返回索引未涵盖的列的查询将使用较少的逻辑I / O(LIO),因为没有额外的聚簇索引b树搜索步骤? create table T ( Id int identity(1,1) primary key,-- clustered or non-clustered? (surrogate key,may be used to join another table) A .... -- A,B,C have mixed data type of int,date,varchar,float,money,.... B .... C .... ....) create index ix_A on T (A) create index ix_..... -- Many indexes can be created for queries -- Common query is query on A,C,.... select A,B from T where A between @a and @a+5 -- This query will have less LIO if the PK is non-clustered (seek) select A,C from T where B between @a and @a+5 .... 标识列上的聚类PK很好,因为: >它单调增加,因此插入时不会分页.据说批量插入可以像堆(非聚集)表一样快 但是,如果不将其设置为群集,问题中的查询会更快吗? **更新:** 解决方法默认情况下,PK是聚集的,在大多数情况下,这很好.但是,应该问哪个问题: >我的PK应该聚集在一起吗? PK和Clustered索引是2个不同的东西: > PK是一种约束. PK用于唯一标识行,但没有存储概念.但是,默认情况下(在SSMS中),如果尚未存在聚簇索引,则由唯一聚簇索引强制执行. 现在我们最终得出两个问题: >我如何唯一标识表格中的行(PK) 这取决于如何: >您设计数据模型 首先,您需要聚集索引吗?如果批量插入,则将无序数据存储到HEAP(与群集中的有序数据相比)更有效.它使用RID(行标识符,8个字节)来唯一标识行并将其存储在页面上. 聚集索引不应该是随机值. 如果经过一些数据和查询分析,您发现在群集PK中进行密钥查找之前,您通常会使用相同的索引来获取数据,您可能会将其视为聚簇索引,尽管它可能无法唯一标识您的数据. 聚簇索引键由要索引的所有列组成.如果没有唯一约束,则添加uniquefier列(4个字节)(重复的增量值,否则为null). 然后,一旦弄清楚如何唯一地标识表中的行,就可以添加PK.如果您认为不在查询中使用它,请不要将其创建为群集.如果您有时需要查询它,仍然可以创建另一个非聚簇索引.请注意,PK将自动创建唯一索引. 非聚簇索引将始终包含聚簇键.但是,如果索引列(键列)覆盖,则聚簇索引中不会有任何键查找. 聚集索引应该是唯一的并且尽可能地窄 现在是时候编写一些SQL来创建表,聚簇和非聚簇索引和约束. 这是理论上的,因为我们不知道您使用的数据模型和数据类型(A和B). (编辑:李大同) 【声明】本站内容均来自网络,其相关言论仅代表作者个人观点,不代表本站立场。若无意侵犯到您的权利,请及时与联系站长删除相关内容! |