SQL Serverの：インデックスが実行計画

Question

に基づいて無視され、私はこの文

UPDATE QP.LocalMessage WITH (UPDLOCK, ROWLOCK) 
SET StatusId = 0 
WHERE StatusId = 1 AND DateLockedUntil <= @DateNow 

を実行し、我々はすぐに

CREATE NONCLUSTERED INDEX [IX_LocalMessage_ProcessingLocked] 
    ON [QP].[LocalMessage] ([DateLockedUntil] ASC) 
    WHERE ([StatusId] = (1)) 

しかし、一見した後に実行するには、このアップデートのインデックスを作成したストアドプロシージャを持っています使用されている実行計画では、この索引を使用しておらず、代わりにクラスター索引スキャンを使用しています。これは、少なくとも2秒以下で実行されるこのステートメントを必要としますが、12-15秒に達する時刻が表示されます。私はなぜそれがインデックスを無視しているのか理解したいと思います。

Answer 1

非クラスタ化インデックスを使用する場合、SQL Serverはキー参照操作を行う必要があります。 select文では、これを回避することはできますが、これは避けることはできません。

述語によって返されるレコードの数が多い場合は、ノンクラスタード・インデックスのシークおよびキー・ルックアップよりもクラスタ・スキャンを実行する方がよいでしょう。

クエリがパラメータ化されているため、SQL Serverは返されるレコード数を確認できません。あなたはテーブル全体を更新することができます。

一部の実行ではレコードが数個しか更新されず、ノンクラスタード・インデックス・シークを使用できる場合は、「with recompile」句を使用してプロシージャを構成できます。これにより、SQL Serverは、プロシージャが受け取る各パラメータ値の計画を分析できます。別のオプションは、クエリで "option（recompile）"を使用することです。

ただし、更新されるレコードの数が少ない場合、SQL Serverはノンクラスタードインデックスのみを使用することに注意してください。

また、テーブル名以外に「（index = yourindexname）」をクエリヒントとして使用し、統計情報と統計情報を分析して、ノンクラスタードインデックスを使用したときの状態がどれほど悪いかを知ることができますクエリでそれを行うべきではありません。

Answer 2

include (StatusId)の場合、クエリでフィルタリングされたインデックスを使用できます。

CREATE NONCLUSTERED INDEX [IX_LocalMessage_ProcessingLocked_Include] 
    ON [QP].[LocalMessage] ([DateLockedUntil] ASC) 
    include (StatusId) 
    WHERE ([StatusId] = (1)) 

dbfiddle：http://dbfiddle.uk/?rdbms=sqlserver_2016&fiddle=816af692f8993ce8844b5b5c7182f7a1

---

参考：

• Filtered Indexes: Just Add Includes - Erik Darling