Ответ 1
ARITHABORT
часто ошибочно определяется как причина.
Фактически с версии 2005, когда ANSI_WARNINGS
включен (как и в ваших соединениях) ARITHABORT
неявно в любом случае, и этот параметр не имеет реального эффекта.
Однако он имеет побочный эффект. Чтобы разрешить случаи, когда ANSI_WARNINGS
выключен, настройка ARITHABORT
используется как один из ключей кеша плана, что означает, что сеансы с разные настройки для этого не могут совместно использовать друг друга.
План выполнения, кэшированный для вашего приложения, не может быть повторно использован при запуске запроса в SSMS, за исключением того, что оба они имеют один и тот же ключ кеша плана, поэтому он получает новый план, скомпилированный, который "обнюхивает" значения параметров, которые в настоящее время тестируются. План для вашего приложения, скорее всего, был скомпилирован для разных значений параметров. Эта проблема известна как "обнюхивание параметров".
Вы можете получить и сравнить оба плана выполнения с чем-то вроде
SELECT usecounts, cacheobjtype, objtype, text, query_plan, value as set_options
FROM sys.dm_exec_cached_plans
CROSS APPLY sys.dm_exec_sql_text(plan_handle)
CROSS APPLY sys.dm_exec_query_plan(plan_handle)
cross APPLY sys.dm_exec_plan_attributes(plan_handle) AS epa
where text like '%INSERT INTO GeocacherPoints (CacherID,RegionID,Board,Control,Points)%'
and attribute='set_options' and text not like '%this query%'
Раздел параметров в XML сообщает вам значение времени компиляции параметров.
См. Медленное приложение, быстро в SSMS? Понимание тайн производительности для более.
Планы выполнения
Вы предоставили оценочные планы выполнения, а не фактические планы выполнения, но видно, что только первый план запроса параметризуется, и он был скомпилирован для следующих значений.
<ParameterList>
<ColumnReference Column="@Dec31" ParameterCompiledValue="'2013-12-31'" />
<ColumnReference Column="@Jan1" ParameterCompiledValue="'2013-01-01'" />
<ColumnReference Column="@Board" ParameterCompiledValue="(71)" />
</ParameterList>
Второй план выполнения использует переменные, а не параметры. Это существенно меняет ситуацию.
DECLARE @Board INT
DECLARE @Jan1 DATE
DECLARE @Dec31 DATE
SET @Board=71
SET @Jan1='January 1, 2013'
SET @Dec31='December 31, 2013'
INSERT INTO GeocacherPoints
SQL Server не нюхает определенное значение переменных и генерирует общий план, аналогичный использованию OPTIMIZE FOR UNKNOWN
подсказки. Оценочные подсчеты строк в этом плане намного выше, чем в первом плане.
Вы не указываете, что является быстрым планом, и это медленный план. Если тот, у кого есть переменные, быстрее, то, вероятно, вам нужно обновить статистику, вы можете столкнуться с проблемой, описанной здесь. Статистика, оценки строк и столбец с возрастающей датой если тот, который использует параметры, будет быстрее, вы сможете достичь переменного нюхания и заставить его принимать во внимание фактические значения переменных с помощью подсказки OPTION (RECOMPILE)
.