8

问题“如何减少简单选择查询的响应时间?”的评论 告诉:

  • “LaunchDate 上的数据类型是什么?如果是 DATETIME 或 DATETIME2,索引不太可能做太多事情,因为它们包含时间部分 – OMG Ponies”

  • “@OMG - 为什么 DateTime 列上的聚集索引不能提高性能?查询是一个范围扫描,它允许快速范围索引查找,因为所有数据都在顺序块中?半相关...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列上的聚集索引不能提高性能?如果索引或因为它们包含时间部分,
为什么索引可能不会做很多事情?DATETIMEDATETIME2

我很欣赏说明DATETIME列索引不会提高性能的脚本。

更新:另外,OMG 是否暗示DATEtype 列上的索引会有所帮助,但不是DATETIMEDATETIME2

4

2 回答 2

4

我读过另一个问题,不知道 OMG ponies 是什么意思

3分

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

寻找或扫描

根据统计数据,如果LaunchDate > @date意味着 90% 的行,那么很可能会发生扫描。如果它非常有选择性,则更有可能进行搜索。

不管集群还是非集群!

什么指数?

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

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

现在,任何非聚集索引都是指默认假设为PK的聚集索引。所以 primaryKeyColumn 已经隐式包含了。

迷信

不过,COUNT(primaryKeyColumn) 是一种迷信。因为PK不允许NULL,所以相当于

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

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

所以你只需要一个关于 LaunchDate 的索引,不管是集群的还是非集群的

于 2010-11-20T12:12:19.850 回答
0

如果您的应用程序使用导致隐式数据类型转换的日期时间,则不会使用日期列上的索引。如果查看执行计划,您会看到有一个内部函数应用于列。解决方案是将日期列更改为时间戳(4)或调整客户端应用程序以使用日期而不是日期时间。

于 2014-03-05T08:32:09.603 回答