可能重复:
SQL Server 聚集索引 - 索引顺序问题
我知道聚集索引中的列顺序很重要。
我计划在 where 子句中始终涉及的 3 列上添加聚集索引 - 一个 int、bit 和 datetimeoffset 列。此外,datetimeoffset 列存储增量值。
将 datetimeoffset 列作为聚集索引中的第一个列是否有意义?欣赏它。
可能重复:
SQL Server 聚集索引 - 索引顺序问题
我知道聚集索引中的列顺序很重要。
我计划在 where 子句中始终涉及的 3 列上添加聚集索引 - 一个 int、bit 和 datetimeoffset 列。此外,datetimeoffset 列存储增量值。
将 datetimeoffset 列作为聚集索引中的第一个列是否有意义?欣赏它。
列顺序对所有索引都很重要,而不仅仅是聚集索引。
最佳列顺序由多个因素决定:
您是否会仅使用其中一列而不使用其他列来查询此表?如果您的索引被定义为ColumnA, ColumnB
... 并且您执行的查询仅使用 过滤ColumnB
,则无法使用该索引,因为ColumnB
它不在索引的前沿。
每列中的值的选择性如何?被索引的列中包含的不同值越多,索引就越有效。这也是您可能不想将bit
列包含在索引中的原因,因为只有 2 个可能的值。更具选择性的列更适合处于领先地位。
正如迈克尔所提到的,索引中的列顺序与 WHERE 子句中的内容直接相关。
为了说明这一点,作为测试,我创建了三个表,每个表都有一个不同的列作为聚集索引中的第一列。然后,我用 10,000 行数据填充它们。
对所有三个表执行相同的 SQL 查询会产生非常不同的性能结果:
set statistics io on
set statistics time on
select * from DtFirst where DtCol between '4/1/2010' and '6/1/2010'
select * from IntFirst where DtCol between '4/1/2010' and '6/1/2010'
select * from BitFirst where DtCol between '4/1/2010' and '6/1/2010'
set statistics io off
set statistics time off
统计如下:
第一个表(日期列在前)
扫描计数 1,逻辑读取3
CPU 时间 = 0 毫秒,经过时间 = 0毫秒。
第二个表(日期列秒)
扫描计数 1,逻辑读取29
CPU 时间 = 0 毫秒,经过时间 = 113毫秒。
第三个表(第三个日期列)
扫描计数 1,逻辑读取29
CPU 时间 = 0 毫秒,经过时间 = 145毫秒。
如您所见,在聚集索引中日期列排在首位的表上查询日期显然会产生更好的结果。