今日、MSSQL でパラメーターのスニッフィングに遭遇し、OPTION RECOMPILE を使用して、パラメーターを使用した場合とパラメーターを使用しなかった場合で 2.5 秒かかったクエリを高速化しました。別の開発者マシンでは、OPTION RECOMPILE なしでまったく同じクエリを実行でき、非常に高速に実行されました。
あるマシンでは OPTION RECOMPILE が必要で、別のマシンでは不要になる原因は何ですか?
今日、MSSQL でパラメーターのスニッフィングに遭遇し、OPTION RECOMPILE を使用して、パラメーターを使用した場合とパラメーターを使用しなかった場合で 2.5 秒かかったクエリを高速化しました。別の開発者マシンでは、OPTION RECOMPILE なしでまったく同じクエリを実行でき、非常に高速に実行されました。
あるマシンでは OPTION RECOMPILE が必要で、別のマシンでは不要になる原因は何ですか?
両方のマシンが同じサーバーに接続していたと仮定すると、不適切なプランが 2 つの接続間で共有されない原因となった設定の違いがあった可能性があります。
接続で以前にキャッシュされたプランを再利用するには、 、 、、およびデフォルト スキーマ (クエリが暗黙的な名前解決に依存している場合) などANSI_NULLS
、かなりの数の設定 (プラン キャッシュ キー) が同じである必要があります。ARITHABORT
Language
DATEFIRST
これらは、(接続間で同じにする必要がsys.dm_exec_plan_attributes
あるもの)を見ることで表示できます。is_cache_key=1
is_cache_key=1
属性の完全なリスト
dbid_execute
required_cursor_options
compat_level
parent_plan_handle
date_format
language_id
status
merge_action_type
is_replication_specific
objectid
acceptable_cursor_options
date_first
set_options
user_id
dbid
optional_spid
optional_clr_trigger_objid
optional_clr_trigger_dbid
set_options
ここに記載されているようにcursor_options
、さまざまなオプションを構成するビット フラグです。私の実験 では、実際にはではなくを参照しています。user_id
schema_id(default_schema_name)
principal_id