Ефективність збережених процедур проти необроблених запитів

Я багато читав з обох сторін цієї дискусії: чи є значне збільшення продуктивності, використовуючи лише збережені процедури над необробленими запитами? Мене спеціально цікавить SQL Server, але мені цікаво будь-яка база даних.

Це менше, ніж у SQL Server 2008 і вище, але він все ще є. Це зводиться до того, що кеш плану виконання та SQL Server можуть автоматично параметризувати запити, які надсилаються. При використанні збережених процедур (у яких немає динамічного SQL всередині них) запити вже параметризовані, тому SQL Server не робить ' не потрібно генерувати план для кожного запиту під час його запуску, оскільки плани вже зберігаються в кеші плану.

І не забувайте про проблеми безпеки (динамічний SQL, мінімальні дозволи та ін.), Які усуваються під час використання збережених процедур.

Коли додаток використовує динамічний SQL проти базових таблиць для вибору, вставлення, оновлення та видалення даних у таблицях, програма повинна мати права на всі ці об’єкти безпосередньо. Тож якщо хтось використовує SQL Injection, щоб потрапити на сервер, він матиме права запитувати, змінювати або видаляти всі дані в цих таблицях.

Якщо ви використовуєте збережені процедури, вони мають лише право виконувати збережені процедури, отримуючи назад лише ту інформацію, яку зберігає процедура. Замість того, щоб видавати оперативу швидкого видалення та видаляти все, їм потрібно було б розібратися, які процедури можна використовувати для видалення даних, а потім з'ясувати, як використовувати процедуру для цього.

З огляду на те, що SQL Injection - це найпростіший спосіб проникнення в базу даних, це дуже важливо.

Як доповнення до відповіді Денні, не рідкість знаходити системи, де значна пам'ять буферного пусту витрачається на спеціальні плани виконання одноразового або низького використання, створені в результаті запитів, що використовуються в документах.

Найгірші випадки останнім часом, 8 ГБ, виділених на екземпляр, 3 ГБ кеш-плану, 2,5 ГБ одноразового використання. Більшість з них були SQL2005, тому не було можливості спробувати оптимізувати налаштування спеціальних робочих навантажень.

Звичайно, важче включити продуктивність у виправдання процедур над необробленими запитами. Один з найсильніших аргументів для мене зараз - "Якщо ви використовуєте процедури, мені набагато простіше допомогти, коли виникають проблеми з продуктивністю". Динамічний / linq / orm інтерфейс не заважає вам налаштувати, але він може серйозно обмежити ваші можливості.

SQL Server кешує та оптимізує збережені процедури та спеціальний SQL таким же чином. Наприклад, ця процедура:

create procedure dbo.TestSB(@id int) as select * from Orders where id = @id

Буде оптимізовано та кешовано ідентично:

select * from Orders where id = @id

Однак наступний спеціальний SQL не може бути кешований ефективно з-за твердо кодованого значення:

select * from Orders where id = 42

Хоча ефективність однакова, є вагомі причини використовувати збережені процедури. Збережені процедури забезпечують чіткий поділ між DBA і розробниками додатків. Добре мати додатковий рівень захисту між вашими цінними даними та програмами, що постійно змінюються :)