我有一个典型的表，它有一个主键整数Id和一个DateTime列，用于记录行创建的时间。理论上，Id列的顺序应该始终与DateTime列的顺序相同。我的应用程序做了一个ORDER BY CreateDateTime DESC，我打算为CreateDateTime列添加一个索引，但后来我意识到主键上的聚集索引应该完成同样的事情，即使它在语义上不正确，也许我应该按Id排序，以防止创建另一个索引。你会添加CreateDateTime索引吗?如果它是一个LastUpdatedDateTime列(意味着偶尔更新索引)呢?
"in theory"…如果实践与理论不相符又有什么关系呢?
如果是，创建索引并按日期字段排序。
如果您不打算进行日期范围搜索，则不要添加索引并按主键排序。我认为语义仍然是正确的，因为您是按插入行的顺序列出的。PK正在为您跟踪该订单，而不是DateTime。
这是假设CreateDateTime在插入行时总是使用getdate()或comparable。如果您预计该日期将以其他方式创建，我将使用CreateDateTime上的索引，并在Order By子句中使用它。
使用Id。它将更好地解释时区更改
我有几个场景，我们在datetime列上有一个聚集索引。这样做效果很好，因为数据总是在增加(意味着页面上的热点，但没有页面分割)，而且几乎所有查询都在日期范围上，而不是在任何其他数据上的上。但这是针对大量事务数据的，而不是针对实体的。
你要做很多查询表特别是基于datetime列吗?如果不是，那么我认为您不会从索引中获益—坚持使用实际标识符作为集群键。更重要的是，如果我们谈论的是最近更新的列——您的查询中有多少百分比会使用这样的索引?这似乎不会给你带来太多好处(但根据数据更新的频率，它可能会让你付出很多代价)。
我们到底在谈论什么样的实体?这些用户、救护车、芭比娃娃、论坛帖子、火山，还是别的什么?每天、每周、每月要增加多少行?你对他们进行了什么样的查询?了解查询的数量和类型对确定索引策略有很大帮助。