【问题标题】:Creating a Non Clustered Index with a DateTime column as key创建以 DateTime 列为键的非聚集索引
【发布时间】:2012-04-05 21:26:27
【问题描述】:

我正在优化我们系统上经常使用的查询。 where 子句类似于

WHERE J.Visibility > 11 
and J.isactive='true' 
and J.isdeleted='false' 
AND (
       CutOffDate > '2012-04-05 00:00:00.000' 
       OR J.CreatedOn > '2011-10-08 00:00:00.000'
    ) 
AND J.Country = 'India' 
AND J.City='Bangalore' 
AND (J.Type > 0 AND J.Type < 230)  
AND J.Category in (20)

已经存在具有 City、Type、Visibility、IsActive、IsDeleted 的 NC 索引(Index1)。我使用上述字段创建了一个新的 NC 索引,但也在开头添加了 CreatedOn、CutOffDate 和 Category。

因此,新索引 (Index2) 上的键是 City、Category、CreatedOn、CutOffDate、Type、Visibility 等。 CreatedOn 和 CutOffDate 均按降序排列。但是,当我运行查询时,实际的执行计划仍然对 Index1 而不是 Index2 进行了索引扫描。鉴于 DateTime 条件,我会认为 Index2 会是更好的选择,并且会导致索引搜索。但那并没有发生。

在调查为什么会发生这种情况时,我遇到了this MS article,现在我想知道是否需要像文章中提到的那样创建具有日期时间的索引。当我在 Google 上搜索时,我没有发现其他任何地方都提到过这种使用日期时间创建索引的技术,因此想知道其他人是怎么做的?

【问题讨论】:

    标签: sql-server sql-server-2005 indexing


    【解决方案1】:

    什么是准确索引定义? (City, Category, CreatedOn, CutOffDate, Type, Visibility) 上的索引不能用于您的查询。实际上,假设您有一个标准,该标准在两个字段上使用不等式比较 (&gt;) 并在它们之间使用 OR 条件,因此没有索引可能有助于比较的日期时间部分。您链接的文章与您的问题完全无关。

    为了让我们提出一个好的索引,您必须准确地告诉我们表的定义、您使用的确切查询以及每列中的基数(不同值的数量)。

    【讨论】:

    • 嗯,这就解释了为什么选择 Index1 而不是 Index2 以及我嗅到了错误的踪迹。但是删除其中一个字段和 OR 条件是否有助于使用日期时间索引? where 子句的条件因用户在应用程序中所做的选择而异。我真的无法在这里提供所有细节。但是,表中有超过 250,000 行,CreatedOn > Date 导致大约 40,000 行,这就是为什么我想使用具有 CreatedOn 的索引的原因。此外,stackoverflow.com/questions/10028225/… 是我为此所做的更改
    • 另外,(20,30,40) 中的 Category 是否有资格作为 OR 条件的相等比较使用具有 Category 的索引?
    • 对单个列的不等式比较可能受益于索引。但是由于索引tipping point,这是一条危险的道路。大多数情况下,时间序列类型的数据使用时间值(例如CreatedOn)作为聚集索引的最左边的键,因为绝大多数查询请求来自特定时间间隔的数据(即。 range scan)
    猜你喜欢
    • 2021-01-14
    • 1970-01-01
    • 1970-01-01
    • 2013-01-24
    • 2013-12-02
    • 1970-01-01
    • 2017-05-08
    • 2011-08-21
    • 2021-09-23
    相关资源
    最近更新 更多