sql-server - 如果是 DATETIME 或 DATETIME2，为什么索引可能不会做太多事情，因为它们包含时间部分？

Question

对 question "How to decrease response time of a simple select query?" 的评论告诉:

• “LaunchDate 上的数据类型是什么？如果是 DATETIME 或 DATETIME2，索引不太可能起多大作用，因为它们包含时间部分 - OMG Ponies”

• “@OMG - 为什么 DateTime 列上的聚集索引不能提高性能？该查询是范围扫描，它允许快速范围索引查找，因为所有数据都在顺序 block 中？半-相关...msdn.microsoft.com/en-us/library/ms177416.aspx – 卡尔加里编码器”

• “Calgary Coder:DATETIME/2 包含时间 - 索引，无论是聚集索引还是非聚集索引，都适用于具有重复时间但不包含范围的日期。– OMG Ponies”

我在DATETIME类型列LaunchDate上创建了一个带有聚集索引的测试表，并观察索引查找类似于上述问题中引用的查询:

SELECT COUNT(primaryKeyColumn) 
FROM   MarketPlan 
WHERE  LaunchDate > @date

而不是表或索引扫描。

为什么 DateTime 列上的聚集索引不能提高性能？
如果是 DATETIME 或 DATETIME2，为什么索引不太可能发挥作用，因为它们包含时间部分？

我希望有一个脚本能够说明 DATETIME 列的索引不会提高性能。

更新:此外，OMG 是否暗示 DATE 类型列上的索引会有帮助，但对 DATETIME 和 DATETIME2 没有帮助？

Answer 1

我读过另一个问题，不知道 OMG 小马是什么意思

3分:

• 索引是聚集索引还是非聚集索引并不重要:
• 是否也包括时间并不重要
• 它必须有用

搜索或扫描:

根据统计数据，如果 LaunchDate > @date 表示 90% 的行，则很可能会发生扫描。如果它是非常有选择性的，那么寻找的可能性就更大。

无论集群还是非集群!

什么索引？

这样的查询需要 LaunchDate 和 PrimaryKeyColumn 上的索引

SELECT COUNT(primaryKeyColumn) 
FROM   MarketPlan 
WHERE  LaunchDate > @date

现在，任何非聚集索引都是指默认为PK的聚集索引。因此，primaryKeyColumn 已经隐式包含在内。

迷信

但是，COUNT(primaryKeyColumn) is a superstition 。因为PKs不允许NULL，所以相当于

SELECT COUNT(*) 
FROM   MarketPlan 
WHERE  LaunchDate > @date

SELECT COUNT(1) 
FROM   MarketPlan 
WHERE  LaunchDate > @date

因此，您只需要 LaunchDate 上的索引，无论是集群索引还是非集群索引