【发布时间】：2010-11-05 20:46:26
【问题描述】：
如果我的 SQL Server 表在日期时间字段上具有聚集索引，并且在插入之前设置为 DateTime.Now（来自 C#），那么索引应该升序还是降序以避免重新组织表？
谢谢。
【问题讨论】：
标签： sql-server clustered-index
【发布时间】：2010-11-05 20:46:26
【问题描述】：
阅读此http://www.sqlskills.com/BLOGS/KIMBERLY/post/GUIDs-as-PRIMARY-KEYs-andor-the-clustering-key.aspx
如果经常基于日期时间字段读取，则好的选择是日期和身份的复合键 - 按该顺序（日期，身份）。
【讨论】：
-
我无法强调将您的 DateTime 作为复合聚集键中的第一个字段有多大帮助。它可能无法与始终具有 int 标识的完美模型相结合，但是当您不断查询（例如，过去 1 小时内的日志条目）时，问题本身就是将 DateTime 作为主键的一部分。尤其是如果您的 DateTime 字段的选择性低于 95%（意味着有很多非唯一值），那么这就是您要达到索引并获得预期性能的方式。
并不重要 - 但 DateTime 真的保证是唯一的吗？我会避免在 DateTime 上放置一个聚集索引 - 我会改用 INT IDENTITY 或 BIGINT IDENTITY，并在 DateTime 上放置一个常规的非聚集索引（因为这真的不能保证是唯一的......）
马克
PS：与主键一样，关于集群键应该是什么的普遍共识是：
- 唯一（否则 SQL Server 将通过向其添加 4 字节唯一符来使其“唯一”）
- 尽可能窄
- 静态（永不改变）
- 永远增加
组成聚集键的列（包括那个 4 字节唯一符）被添加到每个非聚集索引中的每个条目中 - 因此您希望尽可能保持这些列。
PS 2：集群键被添加到每个非聚集索引，因为这是 SQL Server 在非聚集索引中找到搜索值后检索整个行的方式。可以这么说，它是数据库中行的“位置”。因此，它应该是唯一的并且狭义。
【讨论】：
-
如果它 NOT 是唯一的，那么 SQL Server 将自动添加一个 4 字节的“唯一性” - 如果可能，尽量避免这种情况！
-
谢谢，不知道。那么，鉴于有问题的表有一个唯一标识符的 PK，在日期时间字段和 PK 上创建聚集索引会更好吗？
-
此外，GUID 在用作集群键时会产生非常糟糕的性能，因为它们本质上是完全随机的。根据经验，这会导致大量索引碎片和较差的性能。避免在聚集索引中使用 GUID！
-
不要忘记您的聚集键存储在该表的每个索引的每一行中，作为返回聚集索引的指针。所以，你的聚集索引越大，你的非聚集索引就越大（越慢）。
-
聚集索引不需要是唯一的。 SQL Server 默认包含一个带有主键列的聚集索引，因此唯一的就是 PK。