「時々」遅いクエリの診断に関するアドバイス

カバリングインデックスを介してインデックス付きビューから結果を返すストアドプロシージャがあります。通常、高速（約10ミリ秒）で実行され、最大8秒まで実行されることもあります。

ランダム実行の例を次に示します（注：これは低速ではありませんが、クエリテキストは、渡される値を除いて同じです）。

declare @p2 dbo.IdentityType
insert into @p2 values(5710955)
insert into @p2 values(5710896)
insert into @p2 values(5710678)
insert into @p2 values(5710871)
insert into @p2 values(5711103)
insert into @p2 values(6215197)
insert into @p2 values(5710780)

exec ListingSearch_ByLocationAndStatus @statusType=1,@locationIds=@p2

スプロックは次のとおりです。

ALTER PROCEDURE [dbo].[ListingSearch_ByLocationAndStatus]
    @LocationIds IdentityType READONLY,
    @StatusType TINYINT
AS
BEGIN
    SET NOCOUNT ON;

    SELECT      -- lots of fields
    FROM        [dbo].[ListingSearchView][a] WITH (NOEXPAND)
    INNER JOIN  @LocationIds [b] ON [a].[LocationId] = [b].[Id]
    WHERE       [a].[StatusType] = @statusType
    OPTION (RECOMPILE);

（注：OPTION (RECOMPILE)いくつかのアドバイスの後に最近ヒントを追加しましたが、助けにはなりませんでした。

カバーインデックスは次のとおりです（注：ビューには、ListingId一意のクラスター化インデックスもあります）

CREATE NONCLUSTERED INDEX [IX_ListingSearchView_ForAPI] ON [dbo].[ListingSearchView]
(
    [LocationId] ASC,
    [StatusType] ASC
)
INCLUDE ( -- all the fields in the query) WITH (PAD_INDEX = OFF, STATISTICS_NORECOMPUTE = OFF, SORT_IN_TEMPDB = OFF, DROP_EXISTING = OFF, ONLINE = OFF, ALLOW_ROW_LOCKS = ON, ALLOW_PAGE_LOCKS = ON)
GO

showplan XML統計を使用して、プロファイラートレースを配置します。

遅いもの（6秒）と関連する計画は次のとおりです。

私が期待するとおりに見え、クエリが高速の場合と同じ計画です。

計画の費用のかかる部分を拡大すると、次のようになります。

ビュー/バッキングテーブルの完全なスキーマを次に示します（それが役立つ場合）：https : //pastebin.com/wh1sRcbQ

ノート：

• インデックスはデフラグされており、統計は最新です。
• もともとクエリはビューに対してインラインでしたが、安定させるためにSPROCに移動しました。助けていない。
• WITH OPTION (RECOMPILE);ヒントの追加（機能しなかったので、パラメータスニッフィングはできませんか？）
• システム内の他のクエリも実行が遅い場合があり、計画にも明らかな問題はありません。
• ロックできますか？確認方法がわからない。

次に試すことができるアイデアはありますか？

ありがとう

を使用することOPTION (RECOMPILE)は、パラメータスニッフィングの可能性を排除する効果的な方法だとは本当に思いません。

パラメータースニッフィングは、SQLが特定のクエリについて混乱し、新しいパラメーターを検出したために新しいと判断した場合に発生します。新しい実行計画を生成するのに余分な時間がかかるため、時間がかかります。

そのオプションは、SQLが毎回新しいプランを作成するように強制しますが、これはほぼ同じことです。代わりに、次のヒントを使用してデフォルトパラメータを追加することを検討してください。

OPTION(OPTIMIZE FOR(@LocationIds='xx',@StatusType='xx'))

デフォルトのパラメーターを選択するときは、統計的に代表的なセットを使用してください。
これにより、毎回同じプランが強制的に使用され、パラメータスニッフィングの可能性が排除されます。一度それを行い、それが役に立たなかったと判断したら、パラメータスニッフィングを可能性として無視しても安全でしょう。

おそらく、順序を強制しようとするので、常に小さなテーブル（変数）から開始することになります。しかし、ビューでは注意が必要です...

    SELECT  -- lots of fields
    FROM    @LocationIds [b] WITH (NOEXPAND)
            INNER JOIN  [dbo].[ListingSearchView][a] WITH (NOEXPAND) 
                ON [a].[LocationId] = [b].[Id]
    WHERE   [a].[StatusType] = @statusType
    OPTION (FORCE ORDER);

または、テーブル変数をビューに結合する一般的な方法である場合、ループ結合を強制することができます。これは順序を強制します...

    SELECT  -- lots of fields
    FROM    @LocationIds [b] WITH (NOEXPAND)
            INNER LOOP JOIN  [dbo].[ListingSearchView][a] WITH (NOEXPAND) 
                ON [a].[LocationId] = [b].[Id]
    WHERE   [a].[StatusType] = @statusType
    --leaving this here so you don't get an annoying warning 
    OPTION (FORCE ORDER);

クエリエディターでストアプロシージャの名前を書き、ストアプロシージャを選択します。名前を入力してから、推定実行プランの表示を選択するか、（Ctrl + L）をクリックします。この画像の下。

クエリエディターの下部にある[メッセージ]タブのすぐ横に実行計画が表示されます。次に、緑色の線に欠落しているインデックスの詳細が表示され、それを右クリックします。次に、新しいタブで新しいクエリを開き、インデックスを作成します。その後、クエリは高速に実行されます。

そのため、このメソッドを使用して、クエリの診断に時間がかかります。また、使用できるクエリまたはメソッドが非常に多くあります。

問題がブロッキングにあると思われる場合は、楽観的なトランザクション分離レベルRead Committed Snapshotを使用することをお勧めします（これにより、tempDBにオーバーヘッドがかかることに注意してください）。

リファレンス： https : //docs.microsoft.com/en-us/dotnet/framework/data/adonet/sql/snapshot-isolation-in-sql-server

問題が読み取り/書き込みブロッキングにない場合は、ビューにインデックスを追加してみてください（インデックスの最適な選択は、データの選択性に依存します）

CREATE NONCLUSTERED INDEX IX_ListingSearchView (LocationID, StatusType) INCLUDE (other columns...)