>“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？
解决方法
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索引,无论是聚簇还是非聚簇
