Sql Server оптимизация запросов

Question

Я оптимизирую большой SP в Sql Server 2008, который использует много динамического Sql.Это запрос, который ищет в базе данных ряд необязательных параметров, и не хватает кодирования для каждой возможной комбинации параметров. Динамический sql оказался наиболее эффективным методом выполнения этого.Sql striung создается с параметрами и затем передается в sp_executesql со списком параметров.При запуске этого в SSMS с любой комбинацией параметров он выполняется очень быстро (<1 с) и возвращает результаты.Однако при запуске из приложения Windows Form это иногда занимает значительно больше времени. </p>

Я прочитал, что различие в параметре ARITHABORT может привести к этому (ВКЛ по умолчанию в SSMS и ВЫКЛ в ADO), однако я не уверен, какдля того, чтобы включить это, решает проблему или маскирует это?Разница в настройках влияет на сам запрос или просто означает, что Sql Server будет использовать разные кэшированные планы выполнения?Если это так, следует ли очистить кэш и статистику сбросить игровое поле?

Я также прочитал различные точки зрения на настройку OPTION RECOMPILE.Насколько я понимаю, когда sp_executesql используется со списком параметров, каждая комбинация параметров будет создавать плоскость выполнения, однако, поскольку возможные комбинации параметров конечны, это приведет к оптимизированным запросам.Другие источники говорят, что он должен быть установлен на ON в начале любого SP, который использует динамический sql.

Я понимаю, что в разных ситуациях требуются разные настройки, но я хочу разобраться в них, прежде чем пытаться использовать произвольно на моем очень занятомПроизводственный сервер 24х7.Извиняюсь за шалости, я думаю, мой вопрос сводится к:

Что заставляет sql работать по-разному в SSMS и Window Forms?Если это ARITHABORT, то это проблема, связанная с планами выполнения, или я должен включить ее как сервер по умолчанию?Каков оптимальный способ выполнения запросов с динамическим SQL?

Answer 1

Запустите трассировку в SQL Profiler, чтобы увидеть, что на самом деле отправляется на сервер.Конечно, вы должны знать о влиянии трассировки на рабочие серверы.По моему опыту, очень короткие трассировки, ограниченные небольшим набором, не являются большой проблемой для серверов, у которых не очень высокая нагрузка транзакций в секунду.Кроме того, вы можете запустить трассировку на стороне сервера, которая уменьшит ее влияние, так что это вариант для вас.

Как только вы увидите, что на самом деле отправляется в базу данных, это может помочь вам понять проблему.Например, иногда библиотеки БД подготавливают операторы (получая дескриптор для временного хранимого процесса), но это может быть дорогостоящим, если это делается для каждой выдачи запроса, плюс это не требуется с sp_executesql.В любом случае, невозможно точно знать, будет ли это полезно, пока вы не попробуете.