即使我正在使用索引，選擇查詢速度太慢

我不確定在這裏做錯了什麼，但我有一個查詢在有數百萬行的表上運行。即使我正在使用索引，選擇查詢速度太慢

查詢是這樣的：

select * 
    from dbo.table with (index (index_1), nolock) 
      where col1 = 15464 
        and col2 not in ('X', 'U') 
        and col3 is null 
        and col4 = 'E'

指數看起來是這樣的：

CREATE NONCLUSTERED INDEX [index_1] ON [dbo].[table] ([col1], [col2], [col3], [col4]) WITH (FILLFACTOR=90) ON [PRIMARY] 
GO

此選擇仍需要一分鐘時間才能運行。我錯過了什麼？

來源

2016-04-20 Rj.

請小心NOLOCK提示。你的情況可能沒問題，但大多數人並沒有真正理解這個提示的所有後果。 http://blogs.sqlsentry.com/aaronbertrand/bad-habits-nolock-everywhere/ –

嘗試將複合索引放在col1，col4上。重寫col1然後col4，然後剩下的地方。 –

如果我的索引順序是正確的，請問where子句的順序？ –

對於此查詢：

select * 
from table 
where col1 = 15464 and 
     col2 not in ('X', 'U') and 
     col3 is null and 
     col4 = 'E';

最好的指數是table(col1, col4, col3, col2)。查詢應自動使用索引，而不提示。

當根據where子句選擇索引時，應該將相等條件放在第一個 - 後面跟着一個不等的列。出於索引的目的，in和not in是一般的不平等條件。

另外，如果您混合使用數據類型，那麼有時候不使用索引。所以，這假定col1是數字。

來源

2016-04-20 21:32:05

啊，我明白了爲什麼。它是完全有道理的。對不起，還在學習索引:) ..我可以在9分鐘內接受你的答案！謝謝，我的朋友。 –

嗯，它仍然運行超過1分鐘。我是否需要「刷新」SQL的任何內容才能實現這些更改？ –

@Rj。。。。如果查詢處於存儲過程中或以某種方式緩存，則可能需要「選項（重新編譯）」。否則，問題可能只是太多的行匹配。 –

即使我正在使用索引，選擇查詢速度太慢

回答

相關問題