Является ли динамический SQL более производительным, чем статический SQL в SQL Server?

Question

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

Статический режим предпочтителен, когда он не будет препятствовать повторному использованию кеша, и динамический предпочтителен, когда статический будет препятствовать повторному использованию кеша, а повторное использование желательно..

Я спросил, почему статический SQL предотвращает повторное использование кэша, и он сказал:

Очевидно, что когда переменные передаются предикатам операторов, это может предотвратить повторное использование кэшем этого плана выполнения.где DSQL разрешит повторное использование кэша в хранимой процедуре.

Так, например:

select * from mytable where myvar = @myvar

Я не специалист по планам выполнения SQL Server, но это кажетсяиррационально для меня.Почему движок будет хранить статистику в операторе DSQL в хранимой процедуре, а не в статическом операторе SQL?

Answer 1

Преимущество динамического SQL в том, что запрос перекомпилируется при каждом запуске.Это дает преимущество в том, что в плане выполнения могут использоваться самые последние статистические данные в таблице и значения любых параметров.

Помимо того, что статический SQL обладает большей читаемостью, он имеет то преимущество, что ему не нужнобыть перекомпилированным - сохранение шага в выполнении запроса (ну, на самом деле, два, если считать парсинг -> компиляция -> выполнение).Это может или не может быть хорошей вещью.

Вы можете принудительно перекомпилировать статические планы, используя опцию with (recompile).

Иногда вам нужно использовать динамический SQL.Однако, как правило, я бы использовал подсказки компилятора и другие усилия для управления производительностью , прежде чем зависеть от динамического SQL .

Answer 2

С точки зрения сервера SQL, я не думаю, что вы должны много использовать динамический SQL.
Проблемы могут включать в себя:

1. В таблицу памяти будет передаваться только чтение
2. С каждым объединенным значением запрос выполнит перекомпиляцию.

План выполнения в любом случае будет использовать статистику таблицы и другую информацию БД, но вам нужно перекомпилировать план выполнения.Вы можете исправить свои запросы, чтобы использовать LOOP JOIN, HASH JOIN или MERGE JOIN самостоятельно, если чувствуете, что знаете лучше, чем движок SQL Server.В противном случае, просто напишите процедуры так, как они предназначены для написания, и передайте параметры.

По моему мнению, не используйте динамические запросы ... Вместо этого используйте процедуры, в которых каждое изменяемое значение передается в качестве параметра и не имеет жесткого кодирования.Создайте правильные (и меньшее количество) индексы и триггеры для работы с данными.Таким образом, вы также сможете легко использовать функции in memory table variables и memory tables напрямую, в противном случае in memory table variables будут переданы в динамический запрос только для чтения.