問題タブ [parameter-sniffing]

次のコードがあります。

次のクエリがダンプされます。

ご覧のとおり、実際の値 1 と 3 はクエリに挿入されず、代わりにパラメーターとして渡され、最適でない実行プランが選択されることがよくあります。

代わりに、どうにかして Ling-To-Sql を発行させることはできますWHERE [t0].[State] = 1 OR [t0].[State] = 3か?

ssms で実行するのに約 15 秒かかる SQL クエリがありますが、ssrs で実行すると 5 ～ 7 分かかります。私が読んだすべてのものから、これは「パラメータースニッフィング」によるものであるように見えるので、これをバイパスするためにクエリ内で変数を宣言しましたが、まだ複数のパラメーターで問題が発生しています。

私はこれを試しました: https://social.msdn.microsoft.com/Forums/sqlserver/en-US/ee0e8b0c-44ae-4558-9b7e-d287dacfb8a5/multi-value-parameter-sniffing?forum=sqlreportingservices

と：

渡されたパラメータは次のとおりです: @Places

これは、レポートの実行時に 1 つの場所のみを選択した場合に機能しますが、それ以外の場合は次のようなエラーがスローされます。

このエラーの詳細については、ローカル サーバー コンピューター上のレポート サーバーに移動するか、リモート エラーを有効にしてください -------------------------------- クエリデータセット 'dataset1' の実行に失敗しました。(rsErrorExecutingCommand) -------------------------------- レポートの処理中にエラーが発生しました。(rsProcessingAborted)

ParseValues 関数は、http://visakhm.blogspot.in/2010/02/parsing-delimited-string.html から取得されます。

他のアイデアはありますか？

テーブル値のパラメーターにパラメーター スニッフィングを追加することはほとんどまたはまったく価値がないことは確かですが、誰かがこれを確認できるかどうか疑問に思っていましたか?

(INT_LIST は、INT 型の単一の列であるユーザー定義のテーブル型です)

SQL Server 2012 を使用しています。最近、すべてのストアド プロシージャでパフォーマンスの問題が発生していますが、プロシージャ内のコードは非常に高速に動作します。

パラメータのスニッフィングについて何かを見つけたので、すべての手順の回避策としてローカル変数の定義手法を使用しました。

なぜこれがすべての手順で私に起こっているのか、私は自問しました。私の唯一の推測は、すべての手順が単一の OPTIONAL パラメータを使用しているためです。

これは私のすべての手順のヘッダーです

私は正しいですか？それとも他のアイデアがありますか？

最近、SQL 開発で働いている私の同僚の 1 人が次のような問題に遭遇しました。手順はすべての環境で正常に実行されましたが、最もリソースが多い本番環境で実行されました。パラメーター スニッフィングの典型的なケースですが、プロファイラーは、手順全体で 1 つのクエリだけが実行に非常に時間がかかることを示しました。

私は開発に偏っているので (管理経験はほとんどありません)、このクエリを書き直すことを提案しました。

• LEFT JOIN (SELECT DISTINCT ...)と置き換えますNOT EXISTS (SELECT 1 ...)

• テーブルに適切なインデックスを配置しますusr.tpt_udef_article_grouping_buffer(クエリがプロシージャの外で実行された場合、SSMS は労力を 95% 削減することを提案しました)。

また、プロシージャーからの複数の照会が同じパターンを共有していました。

パラメーターのスニッフィングは、(再) 作成後に初めてプロシージャーを実行するときのプランの構築により関連していることを知っています。

私の質問は：

プロシージャ内のクエリの記述方法 (最初から不適切な実行計画) は、パラメータ スニッフィングの外観に有利に働くのでしょうか、それともその効果を悪化させるだけでしょうか?

クエリの 1 つの実行に予想よりもはるかに長い時間がかかったときに、パラメーター スニッフィングに遭遇しました。この問題をもう少し深く掘り下げると、次のことがわかりました。

初めてクエリが実行されると、（SQL Server）はそのクエリの実行計画を作成し、同じクエリが実行された他のn回の実行計画を作成し、最初の実行で結果セットに大きな差異がある場合、パラメータスニッフィングの問題が発生します.

これは私のシナリオでした。

私の質問は、これらのシナリオで SQL Server のパラメーター スニッフィングを克服する方法または回避策はありますか?

• 実行sp_updatestatsすることで、それが起こっているかどうかを確認できます。

• また、問題をキャッチすることもわかっています。プロシージャ キャッシュを監視する必要がquery_hashありquery_plan_hashますsys.dm_exec_query_stats。

• クエリが実行されるたびに新しい実行計画が作成されるため、変数セクションでは使用RECOMPILEしたくありません。SET

しかし、クエリ自体で何かを実行して解決したい問題を検証する代わりに、たとえば「実行時に問題を検出し、必要な場合にのみ新しい実行計画を作成する (毎回ではない)」という意味です。

私は非常に頻繁にパラメータのスニッフィングの問題に直面しているため、役立つ提案やヘルプはすべて大歓迎です。前もって感謝します！

テーブル値パラメーター (TVP) が渡されるストアド プロシージャ (SP) があります。SP 内の同じコードは、SP の外部よりも実行速度が非常に遅くなります。

実行計画を見てみましたが、それらは非常に異なっています。

最初は、これはパラメーター スニッフィングの兆候のように見えましたが、これは TVP のためのものです。これは少し異なる動作をします (私はあまり確信が持てません - どうやら TVP のスニッフィングはありませんか?)。

いずれにしても、新しいローカル TVP を作成してそこに行を挿入すると、適切な実行計画が得られます!

何が起こっている？

編集クエリオプティマイザーのヒントをいくつか試しましたが、機能しません。提案された重複した質問に1つを含めます。それはほとんど悪い計画 (遅いもの) のようであり、行の推定数に関して正しいものです。高速プランの行数の見積もりが正しくありません。