sql-server – 如果它是DATETIME或DATETIME2,为什么索引不能做太

>“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索引,无论是聚簇还是非聚簇

（编辑：李大同）

【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容!