【问题标题】:Column order on a clustered index [duplicate]聚集索引上的列顺序[重复]
【发布时间】:2012-12-09 07:39:20
【问题描述】:

可能重复:
SQL Server Clustered Index - Order of Index Question

我了解聚集索引中的列顺序很重要。

我计划在 where 子句中始终涉及的 3 个列上添加一个聚集索引 - 一个 int、bit 和 datetimeoffset 列。此外,datetimeoffset 列存储增量值。

将 datetimeoffset 列作为聚集索引中的第一个列是否有意义?欣赏它。

【问题讨论】:

  • 您可能不想包含bit 列...

标签: sql-server sql-server-2008-r2


【解决方案1】:

列顺序对所有索引都很重要,而不仅仅是聚集索引。

最佳的列顺序由多种因素决定:

您是否会只使用其中一列而不使用其他列来查询此表?如果您的索引定义为ColumnA, ColumnB...,并且您执行的查询仅使用ColumnB 进行过滤,则无法使用该索引,因为ColumnB 不在索引的前沿。

每个列中的值的选择性如何?被索引的列中包含的不同值越多,索引就越有效。这也是您可能不想在索引中包含 bit 列的原因,因为只有 2 个可能的值。更具选择性的列更适合处于领先地位。

【讨论】:

  • 我真的很感谢你的回复,只是@JebaDaHut 做了一个很好的测试,所以我将他的回复标记为答案。谢谢!
【解决方案2】:

正如 Michael 所说,索引中的列顺序与 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 毫秒。

如您所见,在聚集索引中日期列排在首位的表上查询日期显然会产生更好的结果。

【讨论】:

  • -这太棒了,我真的很感激!谢谢。
猜你喜欢
  • 1970-01-01
  • 1970-01-01
  • 1970-01-01
  • 1970-01-01
  • 2010-09-25
  • 2019-09-27
  • 2015-04-16
  • 2012-08-26
相关资源
最近更新 更多