索引未使用 + sql server 2005答案

【问题标题】：Index not getting used + sql server 2005索引未使用 + sql server 2005
【发布时间】：2011-05-10 16:06:58
【问题描述】：

这是我的查询

Declare @StartDateTime datetime, @EndDateTime datetime

Select @StartDateTime = '2010-11-15', @EndDateTime = '2010-11-16'

Select PracticeCode, AccountNo, ProcCd, Modifier , ChargeDos, Paid as Amt, CreatedDate,
     case When Paid > 0 then 'P' 
          When Paid = 0 and WrittenOff = DueAmt then 'A'
          Else 'O' 
     End as Status
     From Trn_Postings
     Where CreatedDate >= @StartDateTime and CreatedDate <= @EndDateTime
            --and ManualOverride in ('S','F','X','G','O')
            and ManualOverride in ('N','U')

编辑：创建日期是一个日期时间列，其中包含创建记录的日期和时间

我在 CreatedDate 和 ManualOverride 上都有单独的索引。但执行计划显示聚集索引扫描。该表有近百万条记录，在不久的将来可以增长 4 到 5 倍。

最令人惊讶的部分是，如果我像下面这样更改 where 子句，它会同时使用两个索引。我只是不知道为什么。

     Where CreatedDate >= @StartDateTime and CreatedDate <= @EndDateTime
            and ManualOverride in ('S','F','X','G','O')
            --and ManualOverride in ('N','U')

如何让Sql使用索引...

此外，如果我使用 Not in 子句，则不会使用索引。

【问题讨论】：

就目前而言，优化器确实考虑索引。在第一种情况下不使用索引可能是错误的，但很可能不是。你能发布这两种情况的计划吗？
使用索引并不总能获得更好的性能。强制编译器使用索引会变慢的一个简单情况是执行返回 all 行的选择。
select ManualOverride,COUNT(*) from Trn_Postings group by ManualOverride。如果 N 和 U 代表此列中的大多数值，则意味着索引对查询没有那么有用，因此优化器不太可能使用它。
也许分解成 5 个 UNION 会产生更好的结果。它在某些情况下对我有用。请参阅 Quassnoi 回答的第一个案例：stackoverflow.com/questions/1069346/…
@Damien。当然 N 和 U 构成主要部分，但是当数据分布在 5 个月内但我只要求一天时，是什么阻止了它在“CreatedDate”上使用索引。

标签： sql-server-2005 query-optimization sql-execution-plan

【解决方案1】：

我建议在 CreatedDate 和 ManualOverride 上创建一个复合索引。当使用索引可以满足这两个条件时，这就是优化器正在做的事情。

但是一旦它知道它必须使用聚集索引来满足部分查询，它就会显示它忽略了其他索引。它已决定 COST（使用 CreatedDate 索引 + CI 查找 + 条件）> COST（扫描 CI）。这是错误的，但有时会发生这种情况。可能会使用两列上的索引（首先是 CreatedDate）。或者您可以尝试通过使用 INDEX query hint 来强制它。它仍然可以选择忽略提示。

【讨论】：

看起来我必须忍受它:-(...“使用索引”表提示仅在 Sql Server 2008 中可用...我们仍然使用 Sql server 2005...跨度>
@The King - 在 2005 年以下，您仍然可以提供 INDEX 提示 - 使用 OPTION 子句并指定表提示。 msdn.microsoft.com/en-us/library/ms187373(v=SQL.90).aspx

【解决方案2】：

鉴于对于找到与where 子句匹配的每一行，它都必须返回聚集索引以获取数据，如果返回大量数据，则单步执行可能更有效all 并取出它需要的行。

【讨论】：

我的查询返回了 1000 万条记录中的近 10000 条记录，仅占总记录的 1%...

【解决方案3】：

考虑更新统计数据：

update statistics Trn_Postings with fullscan

【讨论】：

我按照你的建议做了......没有任何改变。