Преимущества хранимых процедур и производительность SQL Server 2008

Question

Я пишу интерфейс базы данных, который до сих пор опирался на уровень доступа к данным между пользовательским интерфейсом клиента и базой данных. Как нуб SQL (и поскольку это не приложение с высоким уровнем безопасности), я доволен DAL как альтернативой написанию всей логики базы данных в хранимых процедурах.

На данный момент меня беспокоит скорость. Я понимаю, что SQL Server будет компилировать хранимые процедуры и выполнять их намного быстрее, чем случайные запросы, но я не могу найти какой-либо информации о том, какое влияние это оказывает на производительность.

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

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

В связанной заметке, как производительность SELECT зависит от размера таблицы? Кажется, я не могу найти какие-либо ресурсы по этому вопросу, но, похоже, очень важно решить, как разместить свою базу данных. Сложить, скажем, все свои записи в одну таблицу и положиться на ГДЕ, чтобы изолировать их в логических группах, или же я сгруппирую записи в отдельные таблицы, потому что ВЫБОР 100 из миллиона строк ужасно медленен?

Answer 1

Если вы используете правильно параметризованные запросы (с такими параметрами, как @CustomerID вместо того, чтобы объединять вместе ваш оператор SQL), не должно быть большой разницы между хранимыми процедурами и простыми операторами SQL. Как планы выполнения для простых запросов, так и для хранимых процедур кэшируются SQL Server, и если они часто используются повторно, они не будут выбрасываться из кэшированного слишком быстро. Строго говоря, с точки зрения производительности хранимые процедуры на самом деле не приносят вам большой пользы.

Хранимые процедуры могут быть полезны, поскольку они могут обеспечить еще один уровень безопасности - если весь ваш доступ к данным проходит через хранимые процедуры, «обычным» пользователям, как правило, даже не нужны разрешения на чтение для базовых таблиц.

Что касается размера таблицы: если у вас есть правильное индексирование, простая операция поиска по индексу займет около 3-6 страниц в SQL Server, чтобы добраться до конечного уровня - это до нескольких миллионов страниц данных. Дело в том, что правильное индексирование , и это не всегда легко и очевидно сделать правильно.

Одним из наиболее важных аспектов в SQL Server является правильное получение индекса кластеризации , поскольку он определяет физический порядок ваших данных, а ключ кластеризации является наиболее реплицируемым / наиболее избыточным элементом данных в вашем сервер - так что вы хотите сделать это как можно более эффективным.

Ознакомьтесь с выдающимся сообщением в блоге Кимберли Трипп Дополнительные сведения о ключе кластеризации , а также изучите ее другие публикации в блоге, на которые она ссылается, чтобы получить хорошее представление о том, что делает хороший ключ кластеризации - это абсолютно необходимо , чтобы получить право!

Кимберли - Королева индексации на SQL Server - также содержит массу отличных постов в блоге о том, как выбирать хорошие некластеризованные индексы, а когда меньше, то больше (не переиндексировать вашу базу данных - это может быть даже хуже, чем отсутствие индексов вообще)