SQL Server:日期时间,ASC或DESC上的聚簇索引

Eyv*_*ind 19 sql-server clustered-index

如果我在日期时间字段上有一个带有聚簇索引的SQL Server表,那么在插入之前设置为DateTime.Now(来自C#),索引应该是升序还是降序以避免重组表?

谢谢.

mar*_*c_s 29

没关系 - 但DateTime真的保证是独一无二的吗?我会避免在一个DateTime上放置聚簇索引 - 我会使用INT IDENTITY或BIGINT IDENTITY,并在DateTime上放置一个常规的非聚集索引(因为它确实不能保证是唯一的......)

PS:像主键一样,关于群集密钥的一般共识是:

  • 唯一的(否则SQL Server将通过添加一个4字节的唯一符号来"统一"它)
  • 作为尽可能
  • 静态(永不改变)
  • 不断增加

构成聚簇键的列(包括该4字节唯一符)将添加到每个非聚集索引中的每个条目中 - 因此您希望尽可能保持这些列.

PS 2:将聚簇键添加到每个非聚集索引,因为这是SQL Server在非聚集索引中找到搜索值后检索整行的方式.这是数据库中行的"位置",可以这么说.因此,它应该是独特和狭窄的.

  • 如果它不是唯一的,那么SQL Server将自动添加一个4字节的"唯一符号" - 如果可能的话,尽量避免这种情况! (4认同)
  • 不要忘记,您的聚簇键存储在该表的每个索引的每一行中,作为指向聚簇索引的指针.因此,聚簇索引越大,非聚簇索引的大(越慢)就越大. (3认同)
  • 此外,GUID在用作群集密钥时会造成非常糟糕的性能,因为它们本质上是完全随机的.根据经验,这会导致大量索引碎片和性能不佳.避免在聚集索引中使用GUID! (2认同)

小智 5

阅读http://www.sqlskills.com/BLOGS/KIMBERLY/post/GUIDs-as-PRIMARY-KEYs-andor-the-clustering-key.aspx

如果读取频繁地基于日期时间字段,那么良好的选择是日期和身份的复合键 - 按该顺序(日期,身份).

  • 我不能强调实际将DateTime作为复合群集密钥中的第一个字段是多么有用.它可能不会与始终具有int标识的完美模型相匹配,但是当您不断查询,例如,在最近1小时内记录条目时,问题有助于将DateTime作为主键的一部分.特别是如果你的DateTime字段选择性低于95%(意味着很多非唯一值),那么你就可以按照预期的方式获得指数并获得你的表现. (3认同)