我今天刚刚在 MSSQL 中遇到了参数嗅探,并使用 OPTION RECOMPILE 来加速查询,该查询需要 2.5 秒,而没有参数则需要 2.5 秒。在不同的开发人员机器上,他们可以在没有 OPTION RECOMPILE 的情况下运行完全相同的查询,并且运行速度非常快。
什么可能导致一台机器需要 OPTION RECOMPILE 而另一台不需要?
我今天刚刚在 MSSQL 中遇到了参数嗅探,并使用 OPTION RECOMPILE 来加速查询,该查询需要 2.5 秒,而没有参数则需要 2.5 秒。在不同的开发人员机器上,他们可以在没有 OPTION RECOMPILE 的情况下运行完全相同的查询,并且运行速度非常快。
什么可能导致一台机器需要 OPTION RECOMPILE 而另一台不需要?
假设您的意思是两台机器都连接到同一台服务器,那么可能存在设置差异,导致两个连接之间不共享不适当的计划。
为了使连接重用以前缓存的计划,很多设置(计划缓存键)必须相同,包括、 、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
.