UNKNOWNで使われる統計がどのように算出されているのか検証してみました。パラメータスニッフィングについては以下をご参照ください。UNKNOWNについて次のような説明がされています。オプティマイザーでクエリをコンパイルおよび最適化するときに、強制パラメーター化によって作成されたパラメーターも含め、すべてのローカル変数に対して初期値の代わりに統計データを使用することを指定します。literal_constant特定の値および"不明"の残りの変数の値に指定されています。これらの値はクエリを最適化する過程でのみ使用され、クエリの実行時には使用されません。(Transact-SQL)まずは検証用にテーブルとデータ、インデックスを用意します。ON)GO続いてインデックスの統計情報を更新し、統計情報を確認します。UNKNOWNを使用したストアドプロシージャを作成します。UNKNOWNを使用していない場合まずはUNKNOWNが無い場合のクエリを実行した場合の予測行数は次のとおりとなります。@Param1GOこの場合、パラメータスニッフィングが有効となっており実行プラン作成時のパラメータで最適化されているため、初回実行時のcol3=50の予測行数でプランが作成されていることが分かります。実行プランを削除してからパラメータを変更して実行プランを確認するとプラン作成時のパラメータに応じて予測行数が変わっていることがわかります。UNKNOWNを使用した場合UNKNOWNが有る場合のクエリを実行した場合の予測行数は次のとおりとなります。@Param1GO先ほどのパラメータを使用しているにも関わらず、予測行数が異なっています。先ほど同様に実行プランを削除してパラメータを変更して実行してみます。@Param1GOUNKNOWNが無い場合とは異なり、初回実行時のパラメータに左右されることなく一定の予測行数となっていることがわかるかと思います。density)から全体行(Rows)に対し何%含まれているか計算して予測行数としているようです。NO_INFOMSGSGO先ほど確認した実行プランの予測行数と一致することがわかります。UNKNOWNを使用する場合、統計情報から各データのユニークな値の分布と全体行数を考慮して平均的な行数を予測した実行プランを作るといえるかと思います。値毎の出現頻度までは考慮していないように見えます。今回でいうとcol3=50は件数が多いはずですが、col3のユニークな値と全体行数からしか予測行数を算出していないため。念のためヒストグラムを可視化しておくと以下の通りとなります。UNKNOWNを使う検討をするのもありかと思います。#その分パラメータによっては最速なプランは作成されないためトレードオフではありますが。Server2016】dm_exec_input_bufferについて月別アーカイブはてなブログをはじめよう!utiowaさんは、はてなブログを使っています。ブログを報告するスターをつけました引用をストックしましたストック一覧を見る閉じる引用するにはまずログインしてくださいログイン閉じる引用をストックできませんでした。再度お試しください閉じる限定公開記事のため引用できません。