Каковы реальные мировые плюсы и минусы выполнения динамического SQL команды в хранимой процедуре в SQL Server с помощьюДинамический SQL - EXEC (@SQL) по сравнению с EXEC sp_executesql (@sql)
EXEC (@SQL)
против
EXEC SP_EXECUTESQL @SQL
?
sp_executesql более вероятно, будет способствовать повторному использованию плана запроса. При использовании sp_executesql параметры явно идентифицируются в вызывающей сигнатуре. Эта замечательная статья описывает это process.
Процитированная ссылка на многие аспекты динамического sql: Erland Sommarskog должен читать: «The Curse and Blessings of Dynamic SQL».
Большая проблема в SP_EXECUTESQL заключается в том, что он позволяет создавать параметризованные запросы, что очень хорошо, если вы заботитесь о SQL-инъекции.
выполнить команду
declare @sql varchar (100)
set @sql ='select * from #td1'
if (@[email protected] !='')
begin
set @sql= @sql+' where PickupDay in ('''[email protected]+''','''[email protected]+''')'
end
exec(@sql)
Это можно использовать для SQL-инъекций, если вы помещаете, например, «a»; DROP DATABASE DATABASE_NAME; GO; '; "в переменной @IsMonday –
Статья Using sp_executesql Microsoft рекомендует использовать sp_executesql вместо execute.
Поскольку эта хранимая процедура поддерживает параметра замещения, sp_executesql является более универсальным, чем EXECUTE; и поскольку sp_executesql генерирует планы выполнения, которые с большей вероятностью будут , повторно используемые SQL Server, sp_executesql равен более эффективным чем EXECUTE.
Так, заберите: Не используйте execute заявление. Используйте sp_executesql.
Ваш вынос не всегда стоит. Бывают случаи, когда бонус эффективности отсутствует при использовании sp_executesql, но вы можете защитить свой код от SQL-инъекции. Иногда вы просто не можете использовать sp_executesql как вы можете использовать exec, так что ... кто-то сказал - нет серебряной пули. Я согласен. – OzrenTkalcecKrznaric
Да, Microsoft должна была сказать, что «более вероятно», чтобы быть эффективной ». И, будучи в отрасли в течение нескольких лет , Я видел случаи, когда 'sp_executesql' не может использоваться для замены' execute'. Возможно, я должен указать, что я пытаюсь подчеркнуть: используйте 'sp_executesql' вместо' execute' *, когда это возможно *. – Gan
В наши дни я всегда использовал sp_executesql, все это действительно является оберткой для EXEC, которая обрабатывает параметры & переменных.
Однако не забывайте о ВАРИАНТЕ РЕКОМПИЛИЗАЦИИ при настройке запросов на очень больших базах данных, особенно если у вас есть данные, относящиеся к нескольким базам данных, и используют CONSTRAINT для ограничения сканирования индексов.
Если вы не используете OPTION RECOMPILE, SQL-сервер попытается создать план выполнения «один размер подходит всем» для вашего запроса и будет запускать полное сканирование индекса каждый раз при его запуске.
Это гораздо менее эффективно, чем искать, а значит, потенциально сканируя целые индексы, которые ограничены в диапазоны, которые вы даже не запрашивая: @
Я не думаю, что вы можете parameteize динамического SQL без него ?? –
EXEC ('SELECT * FROM FOO WHERE ID =?', 123) заменит параметр placeholder "?"со значением 123 и затем выполнить запрос, возвращая результат для SELECT * FROM FOO WHERE ID = 123 –
К сожалению, этот синтаксис доступен только для связанных серверов. –