これはちょっと変わったものです... 私は実行に40秒かかるストアドプロシージャを持っています。 ストアドプロシージャの内容を新しいクエリウィンドウにコピーし、2つの入力パラメータ（両方の日付）を変更して宣言して設定し、クエリを実行するように変更します。それは基本的に瞬時、サブ1秒の実行です。 唯一の違いは、ストアドプロシージャは2つの日付をパラメータとして取ります。SQL Server Stored Procは、Management Studioのテキストから実行された同じクエリよりも実行に時間がかかります
誰でも何が起こるか考えていますか？
（私はSQL Server 2005を実行しています）
再コンパイルがパラメータを傍受し、それは何の違いを作ることはできません。あなたはパラメータをマスクする必要がある
This article explains my statement ...
...パラメータ値が コンパイルまたは再コンパイル中に傍受されている...
：
ALTER PROCEDURE [uspFoo]
@Date1 datetime,
@Date2 datetime
AS
BEGIN
DECLARE @IDate1 datetime, @IDate2 datetime;
SELECT @IDate1 = @Date1, @IDate2 = @Date2;
-- Stuff here that depends on @IDate1 and @IDate2
END
ちょうどこれを自分で処理しましたが、あなたは正しいです:) –
+1これは古い投稿であることは分かっていますが、あなたはこの1つを解決しようとしています。 – twoleggedhorse
ランプロファイラを実行し、実行のクエリプランを取得します。相違点を確認してください。クエリをチューニングしたり、特定の計画を実行したりすることができます。
私はDATEとしてパラメータを設定していたために同様の問題が発生していましたが、WHERE句で比較された列はDATETIMEになっていました。比較していたすべての行。上記のようにパラメータのデータ型をDATETIMEに変更するか、またはパラメータをマスクすると、問題が解決されます。
gbnは言うとおり、これはパラメータスニッフィングの問題です。彼の提案に代わる方法は、クエリの最後に次の行含めることです。ところで
OPTION (RECOMPILE)
を、私は再コンパイルのprocのマーキングしようとしている、それは効果がなかった –
http://www.sommarskog.se /query-plan-mysteries.html – Greg