Хранимая процедура MySQL или сложный запрос

Какова эффективность хранимой процедуры? Стоит ли использовать их вместо реализации сложного запроса в вызове PHP / MySQL?

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

Посмотрите на индексы и правильный дизайн таблицы, чтобы получить лучшую производительность.

Yikes, я бы не хотел, чтобы кто-то прочитал эти ответы и получил неправильное впечатление. Существуют некоторые действительно важные различия между реализациями «Сохраненные без исключения» в «MySQL» и «SQL server / Oracle».

См .: http://www.joinfu.com/2010/05/mysql-stored-procedures-aint-all-that/

Каждый, кто задает этот вопрос, предполагает что-то о реализации хранимой процедуры MySQL; они неверно полагают, что хранимые процедуры скомпилированы и хранятся в глобальном кэше хранимых процедур, аналогично кэшу хранимых процедур в Microsoft SQL Server [1] или Oracle [2].

Это не верно. Плоский неверный.

Вот правда: каждое соединение с сервером MySQL поддерживает собственный кеш хранимых процедур.

Потратьте минутку, чтобы прочитать остальную часть статьи и комментарии. Это коротко, и у вас будет гораздо лучшее понимание проблем.

Как было указано мне в предыдущем ответе, любезно предоставленном JohnFX:

«Эффективность работы хранимых процедур в лучшем случае сомнительна и минимальна. Некоторые материалы для чтения по этому вопросу:

http://statestreetgang.net/post/2008/04/My-Statement-on-Stored-Procedures.aspx

http://betav.com/blog/billva/2006/05/are_stored_procedures_faster_t.html

Наслаждаться.

В MySQL или любом другом SQL-сервере как MSSQL или Oracle хранимые процедуры значительно увеличивают скорость запросов, потому что они уже скомпилированы. Хранимые процедуры более безопасны, чем прямые запросы, и как объект в базе данных, которую они могут администрировать владельцем, предоставляя правильный доступ каждому пользователю.

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

Определенно хранимые процедуры скалы !!!!

Из документации MySQL 5.1: хранимые процедуры могут быть особенно полезны в определенных ситуациях:

Когда несколько клиентских приложений написаны на разных языках или работают на разных платформах, но им необходимо выполнять одни и те же операции с базой данных.

Когда безопасность имеет первостепенное значение. Например, банки используют хранимые процедуры и функции для всех общих операций. Это обеспечивает согласованную и безопасную среду, и подпрограммы могут гарантировать, что каждая операция будет правильно зарегистрирована. В такой настройке приложения и пользователи не будут иметь прямого доступа к таблицам базы данных, но могут выполнять только определенные хранимые процедуры.

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

Сохраненные процедуры также позволяют вам иметь библиотеки функций на сервере базы данных. Это функция, разделяемая современными языками приложений, которые позволяют такой дизайн внутри (например, с помощью классов). Использование этих функций языка клиентского приложения полезно для программиста, даже вне сферы использования базы данных.

Абсолютно упрощен. Производительность хранимых процедур равна или немного лучше кода за счет загрузки сервера db. Поскольку большинство систем db связаны с многопользовательским доступом и используют аппаратное обеспечение для сервера db, использование разгрузки кода сервера db, вероятно, выиграет в целом. С высокопроизводительными серверами БД> 4 ядра,> 32 ГБ оперативной памяти, загрузка SP часто не является проблемой.

Хранимые процедуры;

  1. передача меньше данных в запросе – минимальное улучшение скорости для хорошо написанного кода
  2. разбор и кеширование «немного лучше» – минимальное улучшение скорости для хорошо написанного кода
  3. переместите загрузку выполнения на сервер db и клиент (ы) (веб-серверы), потенциально распространяя нагрузку на многие системы. – улучшения скорости очень зависят от фактического кода и количества данных, включая «лишние» данные, переданные. Достаточно немного кода передает больше данных, чем фактически используется (библиотеки db, плохо написанные запросы, выберите * и т. Д.),

Не оптимизируйте на ранней стадии.

Хранимые процедуры имеют много других преимуществ, кроме скорости, и высокая безопасность в списке.

В одной среде программиста преимущества могут быть компенсированы кривой программирования программирования SP, инфраструктурой тестирования SP, множеством методов контроля версий – SP и кодом и т. Д.

Изучение и использование структуры тестирования и профилирования ответит на это окончательно и поможет вам обеспечить лучшую «производительность» для вашего приложения, чем просто выбирать SP или специальные запросы.

Ответ на вопрос «стоит ли это». Если у вас нет рамки для тестирования / профилирования, вы будете только гадать. Любой ответ, основанный на моем коде и оборудовании, вероятно, не имеет отношения к вашему.

Мой опыт в реальном мире на многих веб-приложениях Perl / TCL / PHP / C с использованием хранимых процедур БД (Sybase, Oracle, MS SQL, MySQL, Postgres) НЕ ДОЛЖНО повышать производительность по сравнению со всеми. Но я по-прежнему часто их использую, просто по другим причинам, а не по производительности. Они могут значительно улучшить конкретный сложный запрос, но это редко основная часть кода и общее время обработки.