Хранимые процедуры или sp_executesql в SQL Server: что лучше?
Пересказ статьи Erik Darling. Stored Procedures vs sp_executesql In SQL Server: Is One Better Than The Other
Мне часто задают этот вопрос клиенты, главным образом, в следующих двух конкретных случаях:
- Кто-то мне говорил, что им потребовалось использовать динамический SQL в хранимой процедуре.
- Приложения, отправляющие параметризованные операторы SQL, которые выполняются с помощью sp_executesql.
Часто рекомендации использования динамического SQL возникают из необходимости обработки:
Даже в контексте хранимой процедуры эти вещи могут сильно снизить производительность.
Теперь большая часть SQL, сгенерированного ORM, меня ужасает.
Очень трудно убедить разработчиков в избыточности их кода, даже если это неправильное использование, а не ошибка ORM.
Но посмотрите, простые запросы делаются нормально с помощью ORM (обычно). При условии, что вы:
Вы можете носиться со своими основными CRUD. Я начинаю волноваться, когда кто-то смотрит на запрос ORM и говорит: «О, это отчет…», потому что с помощью ORM вы никак не сможете сгенерировать разумные запросы для отчетов.
Реальный плюс хранимых процедур - это не повторное использование плана, или кэширование, или лучшая производительность. Отдельный параметризованный запрос будет одинаково выполнен в любом контексте, если все учтено.
Их преимущество в дополнительной гибкости при настройке. Вместо одного огромного запроса, с которым имеет дело оптимизатор, вы можете разбить его на много обслуживаемых частей.
Вы также имеете немного больше свободы с различными хинтами, флагами трассировки, перезаписями запроса, уровнями изоляции и т.д.
Другими словами, в конечном итоге ваши потребности в запросах перерастут способность ORM генерировать оптимальные запросы.
А пока используйте то, что можете, чтобы выполнять свою работу.
- Ветвление IF
- Чувствительность к параметрам
- Необязательные параметры
- Локальные переменные
Даже в контексте хранимой процедуры эти вещи могут сильно снизить производительность.
Но код
Теперь большая часть SQL, сгенерированного ORM, меня ужасает.
Очень трудно убедить разработчиков в избыточности их кода, даже если это неправильное использование, а не ошибка ORM.
Но посмотрите, простые запросы делаются нормально с помощью ORM (обычно). При условии, что вы:
- Уделяете внимание индексам
- Не используете длинные предложения IN
- Строго типизируете параметры
- Избегаете AddWithValues
Вы можете носиться со своими основными CRUD. Я начинаю волноваться, когда кто-то смотрит на запрос ORM и говорит: «О, это отчет…», потому что с помощью ORM вы никак не сможете сгенерировать разумные запросы для отчетов.
Процедурная драма
Реальный плюс хранимых процедур - это не повторное использование плана, или кэширование, или лучшая производительность. Отдельный параметризованный запрос будет одинаково выполнен в любом контексте, если все учтено.
Их преимущество в дополнительной гибкости при настройке. Вместо одного огромного запроса, с которым имеет дело оптимизатор, вы можете разбить его на много обслуживаемых частей.
Вы также имеете немного больше свободы с различными хинтами, флагами трассировки, перезаписями запроса, уровнями изоляции и т.д.
Другими словами, в конечном итоге ваши потребности в запросах перерастут способность ORM генерировать оптимальные запросы.
А пока используйте то, что можете, чтобы выполнять свою работу.
Обратные ссылки
Нет обратных ссылок
Автор не разрешил комментировать эту запись
Комментарии
Показывать комментарии Как список | Древовидной структурой