Почему хранимая процедура выполняется быстрее, чем запрос

Я хочу написать простой однострочный запрос, чтобы выбрать только одно значение из базы данных.

Итак, если я пишу хранимые процедуры для этого запроса, а не пишу простой запрос select в коде С#, то я уверен, что хранимая процедура для этого простого запроса выбора будет быстрее, но почему?

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

Ответы

Ответ 1

  Хранимые процедуры быстрее кода SQL

Это миф, производительность всегда эквивалентна, из книги: Разработка решений Microsoft®.NET для предприятия:

SQL - это язык, на котором вы объявляете о своих намерениях относительно операций (запросов, обновлений или операций управления), выполняемых в базе данных. Все, что получает движок базы данных - это текст. Подобно исходному файлу С#, обрабатываемому компилятором, исходный код SQL должен быть каким-то образом скомпилирован для получения последовательности операций с базами данных более низкого уровня - этот вывод проходит под именем плана выполнения. Концептуально генерация плана выполнения может рассматриваться как аналог базы данных при компиляции программы.

Предполагаемый выигрыш в производительности, который гарантируют хранимые процедуры по сравнению с простым кодом SQL, заключается в повторном использовании плана выполнения. Другими словами, при первом запуске SP СУБД генерирует план выполнения, а затем выполняет код. В следующий раз он просто повторно использует ранее сгенерированный план, тем самым выполняя команду быстрее. Все команды SQL нуждаются в плане выполнения.

(Ложный) миф состоит в том, что СУБД повторно использует план выполнения только для хранимых процедур. Что касается SQL Server и СУБД Oracle, преимущество повторного использования планов выполнения распространяется на любые операторы SQL. Цитирование из электронной документации по SQL Server 2005:

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

Споры о том, что SP работают лучше, чем обычный SQL-код, бессмысленны. С точки зрения производительности любой код SQL, попадающий в базу данных, обрабатывается одинаково. Производительность эквивалентна после компиляции. Период.

Ответ 2

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

Ответ 3

"Stored procedures are precompiled and cached so the performance is much better."

Для меня это было душераздирающим, как и для вас, когда вы узнаете, что это было правдой до SQL Server 2005. Эта статья разрушает миф Хранимые процедуры НЕ повышают производительность

Криста Карпентьер из Microsoft Corp. написала оценку хранимых процедур для разработчика .NET

Ответ 4

Сохраненные процедуры предварительно скомпилированы и оптимизированы, что означает, что механизм запросов может выполнять их быстрее. Напротив, запросы в коде должны анализироваться, компилироваться и оптимизироваться во время выполнения. Все это стоит времени.

Ответ 5

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