私はこのクエリを持っています:
select top 100 id, email, amount from view_orders
where email LIKE '%test%' order by created_at desc
実行にかかる時間は 1 秒未満です。
今、私はそれをパラメータ化したい:
declare @m nvarchar(200)
set @m = '%test%'
SELECT TOP 100 id, email, amount FROM view_orders
WHERE email LIKE @m ORDER BY created_at DESC
5 分後、まだ実行中です。パラメータに対する他の種類のテスト (「like」を「=」に置き換えた場合) では、最初のクエリ レベルのパフォーマンスに落ちます。
SQL Server 2008 R2 を使用しています。
で試してみましたがOPTION(RECOMPILE)、6 秒まで落ちましたが、それでもかなり遅いです (パラメーター化されていないクエリは瞬時に実行されます)。頻繁に実行されると予想されるクエリであるため、問題です。
テーブルの列にはインデックスが付けられていますが、ビューにはインデックスが付けられていません。違いが生じるかどうかはわかりません。
このビューは 5 つのテーブルを結合します。1 つは 3,154,333 行 (ユーザー)、1 つは 1,536,111 行 (注文)、3 つは最大でも数十行 (注文タイプなど) です。検索は "user" テーブル (3M 行) で行われます。
ハードコードされた値:
パラメーター ：
アップデート
を使用してクエリを実行しましたSET STATISTICS IO ON。これが結果です（申し訳ありませんが、読み方がわかりません）：
ハードコードされた値:
テーブル「通貨」。スキャン カウント 1、論理読み取り 201。
テーブル「order_status」。スキャン カウント 0、論理読み取り 200。
テーブル「支払い」。スキャン カウント 1、論理読み取り 100。
テーブル「ギフト」。スキャン数 202、論理読み取り 404。
テーブル「注文」。スキャン数 95、論理読み取り 683。
テーブル「ユーザー」。スキャン カウント 1、論理読み取り 7956。
パラメーター ：
テーブル「通貨」。スキャン カウント 1、論理読み取り 201。
テーブル「order_status」。スキャン カウント 1、論理読み取り 201。
テーブル「支払い」。スキャン カウント 1、論理読み取り 100。
テーブル「ギフト」。スキャン カウント 202、論理読み取り 404。
テーブル「ユーザー」。スキャン カウント 0、論理読み取り 4353067。
テーブル「注文」。スキャン カウント 1、論理読み取り 4357031。
更新 2
それ以来、「インデックスの使用を強制する」ヒントを見てきました：
SELECT TOP 100 id, email, amount
FROM view_orders with (nolock, index=ix_email)
WHERE email LIKE @m
ORDER BY created_at DESC
それがうまくいくかどうかはわかりませんが、私はもうこの場所で働いていません。