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 列上的索引会有所帮助，但不是DATETIME吗DATETIME2？

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 回答