1

これが私が抱えている問題です。クエリを実行しているテーブルには 1 億 7000 万行あります。テーブルへの最新のエントリに関する簡単なクエリを実行するストアド プロシージャを作成しました。WHERE次のようにハードコーディングされた文字列を使用して句を作成すると、次のようになります。

SELECT top 500 a.field1 , a.field2, a.field3
FROM database..hugeTable a( nolock )
WHERE a.StartTime > '2012-07-17 10:10:35.477'

とても速いです。1秒未満。StartTime非クラスター化インデックスにあります。

しかし、私が本当に欲しいのはこれです：

DECLARE @fifteenMinutesAgo datetime;
SET @fifteenMinutesAgo = DATEADD(n , -15 , GETDATE());

SELECT top 500 a.field1 , a.field2, a.field3
FROM database..hugeTable a( nolock )
WHERE a.StartTime > @fifteenMinutesAgo

問題は、2 番目のクエリを実行すると、ほぼ 3 分かかることです。

だから私は狂ったようにいじり、検索し始めました。データ型の問題かもしれないと思ったので、さまざまな CAST と CONVERT を試しましたが、成功しませんでした。使用してみOPTIMIZE FORましたが、このバージョンの SQL では動作しないことに気付きました。のデータ型を確認しましたStartTime。タイプdatetimeです。

私が試した別のことは、非常に奇妙でしたが、これは次のとおりです。

DECLARE @fifteenDaysAgo datetime;
SET @fifteenDaysAgo = DATEADD(d , -15 , GETDATE());

SELECT top 500 a.field1 , a.field2, a.field3
FROM database..hugeTable a( nolock )
WHERE a.StartTime > @fifteenDaysAgo

過去 15 分間の検索から過去 15 日間の検索に変更しました。魔法のようにまたしても超速でした！1秒未満。

これにより、SQLが時間を比較するのはどういうわけか難しいと思いましたか? 比較ステートメントに適合するかどうかを確認するために、のTIME部分を調べる必要はありませんでしたか? datetime知らない。ここで私はストローをつかんでいます。

だから私の質問は、どうすればこれを合理的に高速化し、それでも@fifteenMinutesAgo動的に保つことができるでしょうか?

4

1 に答える 1

2

手順に「パラメーター スニッフィング」の問題があるようです。WITH RECOMPILEオプションが役立つはずです

于 2012-07-17T16:44:58.043 に答える