8

動的な SQL があります。実行には約 4 分かかります。代わりに SQL の出力を取得して実行すると、約 20 秒かかります。なぜ不一致なのですか？動的バージョンで SQL を構築するにはある程度の時間がかかることはわかっていますが、それがそれほど高価であるとは想像できません。

誰にもアイデアはありますか？2 つのクエリは同一である必要があるため、クエリ プランのキャッシュがおかしいのではないかと疑っていましたが、実際にはあまり考えがありません。

編集： 出力を取得することで私が何を意味するかを明確にするために。

動的 SQL では、最後の行は

EXEC sp_executesql @myQuery,
    N'@var1 INT,
    @var2 INT,
    @var2 INT',
    @var1,
    @var2,
    @var3

myQuery の値を取得し、独自の SQL ファイルに入れました。これは 20 秒で実行されますが、execute を使用する動的なものは 4 分かかります。

編集 2 パラメータを削除しました。興味深い結果が得られました。動的 SQL ステートメントのパフォーマンスが向上しました。ハードコーディングされたバージョンでは、パフォーマンスが大幅に低下しました。2つは現在ほぼ同等です。

4

4 に答える 4

7

Microsoft SQL Server を使用していると仮定します (質問に「sql」のタグを付けただけです)。

パラメータ値が異なると、最適化プランが異なる場合があります。次に、その最適化プランがキャッシュされ、次に別のパラメーター値でクエリを実行するときに使用されます。しかし、最適化計画は、後続のパラメーター値にとって最適な計画ではありません。

この問題といくつかの回避策に関する記事は次のとおりです: https://www.simple-talk.com/sql/t-sql-programming/parameter-sniffing/

そうです - パラメータ化されたクエリを使用すると、パラメータ化されていない同じクエリを実行する場合と比較して、パフォーマンスが低下する場合があります。

コードを投稿する自由がない場合、これがあなたのケースに当てはまるかどうかはわかりません。

あなたがそれを行うことができないことを尊重します.StackOverflowに投稿することで、暗黙のうちにあなたのコードや言葉をCreative Commons licenseでライセンスすることになります. ただし、雇用主が同意しない限り、雇用主が所有するコードを共有することは適切ではありません。

于 2013-03-15T19:18:53.380 に答える
5

SQL Server 2008 以降を使用している場合は、OPTIMIZE FOR UNKNOWN クエリ ヒントを使用します。動的クエリの最後に次を追加します。

OPTION (OPTIMIZE FOR (@var1 UNKNOWN, @var2 UNKNOWN, @var3 UNKNOWN))

@var1、@var2、@var3 の 3 つの入力を変更してみてください。はい、クエリ オプティマイザーが真にアドホックなもので統計を使用しようとすると、実際にはそれほどコストがかかる可能性があります。1 つ以上の変数がかなり予測可能である場合は、それらを特定の値に最適化し、残りを未知の値に最適化します。詳細については、このリンクを確認してください。

https://blogs.msdn.microsoft.com/sqlprogrammability/2008/11/26/optimize-for-unknown-a-little-known-sql-server-2008-feature/

明確にするために、これは上記の ninjaPixel で示されているように、パラメーター スニッフィングの問題である可能性があります。 OPTIMIZE FOR UNKNOWNクエリ オプティマイザーは統計に基づいてコンパイルを行うため、すべてのクエリを再コンパイルするよりも優れた結果が得られます。

于 2016-12-27T16:11:39.107 に答える
5

Bill Karwin が言うように、これは「パラメータ スニッフィング」の問題である可能性があります。次の行を含めてみてください。

OPTION (RECOMPILE)

SQL クエリの最後に。

ここに、パラメーター スニッフィングとは何かを説明する記事があります。

于 2013-10-23T13:27:50.940 に答える