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

对 question “How to decrease response time of a simple select query?”的评论告诉：

>“launchdate上的数据类型是什么？如果DATETIME或DATETIME2包含时间部分,那么索引不太可能做得太多 – OMG Ponies”
>“@ OMG – 为什么DateTime列上的Clustered Index不能提高性能？查询是一个范围扫描,它允许快速范围索引查找,因为所有数据都在顺序块中？半相关… msdn .microsoft.com / zh-CN / 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？

解决方法

我已经阅读了另一个问题,不知道OMG小马是什么意思

3分：

>索引是群集还是非群集无关紧要：
>时间是否也包括在内也没关系
>它必须是有用的

寻求或扫描：

根据统计数据,如果launchdate>例如,@ date意味着90％的行,然后很可能会发生扫描.如果它具有很强的选择性,则更有可能进行搜索.

无论是群集还是非群集！

什么指数？

像这样的查询需要launchdate和primaryKeyColumn上的索引

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

现在,任何非聚集索引都指的是默认情况下假定为PK的聚簇索引.因此,已经隐含地包含了primaryKeyColumn.

迷信

但是,COUNT(primaryKeyColumn)is a superstition.因为PK不允许NULL,所以它相当于

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

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

所以你只需要一个launchdate索引,无论是聚簇还是非聚簇