高ロック待機のインデックス-修正方法
dbo.sp_BlitzIndexと私のデータベースのメインテーブルに4つのやや似たインデックスがあります。それぞれに、待機とエスカレーションの試行が多数あります。これらがどこから来ているのかわかりません。不足しているインデックスはありません。このテーブルの検索に時間がかかるとは思えないため、これらが選択または挿入によるものかどうかは不明です。次にどこを見ればよいかについて、いくつかの指針が必要です。
CORE.tblCase.idx_tblCase_bClosed_nUserID_PrimaryAgent（2）：
行ロック待機：1;合計時間：0秒。平均継続時間：0秒。
ページロック待機：85;合計時間：92分。平均継続時間：1分。
ロックのエスカレーションの試行：100,965;
実際のエスカレーション：1.テーブルのNCインデックス：1CORE.tblCase.idx_tblCase_bClosed_nActionID_Last_nWorkflowID（27）：
行ロック待機：3;合計時間：26秒。平均継続時間：8秒。
ページロック待機：15;合計時間：10分。平均継続時間：42秒。
ロックのエスカレーションの試行：31,908;
実際のエスカレーション：0。テーブルのNCインデックス：1CORE.tblCase.idx_tblCase_bClosed_nWorkflowID_nActionID_Last（28）：
ページロック待機：112;合計時間：85分。平均継続時間：46秒。
ロックのエスカレーションの試行：31,748;
実際のエスカレーション：0。テーブルのNCインデックス：1CORE.tblCase.idx_tblCase_bClosed_nCaseID_INC（35）：
行ロック待機：2;合計時間：13分。平均時間：6分。
ページロック待機：307;合計時間：399分。平均継続時間：1分。
ロックのエスカレーションの試行：43,090;
実際のエスカレーション：0。テーブルのNCインデックス：1
最初に付記-うーん、これらの結果には少し疑わしい点があります。それらはすべて同じテーブルを言いますが、同時に「テーブルのNCインデックス：1」と言います。つまり、テーブルにはインデックスが1つしかないと思いますが、ここでは4つ表示しています。これらは別のデータベースにある可能性があります。または、sp_BlitzIndexコードにバグがある可能性があります。
それはさておき、ここではいくつかの異なる質問があります。
ブロッキングの問題があるかどうかはどうすればわかりますか？SQL Serverが待機しているものを追跡する待機統計を見てください。そのための私の個人的なお気に入りのツールは sp_Blitz @CheckServerInfo = 1、@OutputType = 'markdown' なので、質問のStackに結果を投稿できます。 （免責事項：私はそれらのスクリプトを開始した会社で働いています。）セクションの1つは、最も重要な待機を示します-最初にそれらに焦点を当てます。主な待機タイプにLCK *が含まれている場合は、おそらくブロッキングの問題があります。
ロックを取得しているクエリを見つけるにはどうすればよいですか？これは、ソフトウェアを監視しないと少し難しい場合があります。私は sp_BlitzCache @SortOrder = 'duration' から始めます。これにより、最も長く実行されているクエリが表示されます。これは、ブロックに関連するクエリを指摘することがあります。ただし、テーブルで実際にフィルタリングすることはできません。
これらのクエリをサポートするために適切なインデックスを設計するにはどうすればよいですか？それは一種の大きな質問です。一般的には、ワークロードをサポートするために必要な数のインデックスが必要ですが、取得する必要のあるロックの数が多いため、削除/更新/挿入（DUI）操作が遅くなるほど多くはありません。テーブルに実際にインデックスが1つしかない場合、DUIクエリは、更新する行を見つけるためにテーブルスキャンを実行している可能性があります。更新を行うときに、これらのテーブルにどのようにアクセスしているかを確認します。
たとえば、電話帳の古典的な白いページがあるとします-姓、名で整理します。名が「Brent」であるすべてのユーザーを更新しようとすると、電話帳全体をスキャンする必要があり、厄介なロック状況が発生する可能性があります。名に個別のインデックスを作成して、更新する必要のある行をすばやく見つけて、テーブルから取り出すことができます。