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

Ответ 1

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

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

Ответ 2

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 сохраняет свой собственный кеш хранимых процедур.

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

Ответ 3

Как было указано мне в предыдущем ответе, любезно предоставленном 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

Enjoy.

Ответ 4

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

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

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

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

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

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

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

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

Ответ 5

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

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

• переносить меньше данных в запрос - минимальное улучшение скорости для хорошо написанного кода
• синтаксический анализ и кеширование "немного лучше" - минимальное улучшение скорости для хорошо написанного кода.
• переместите загрузку выполнения на сервер db и клиент (веб-серверы), потенциально распространяя нагрузку на многие системы. - улучшения скорости очень зависят от фактического кода и количества данных, включая "лишние" данные, переданные. Достаточно немного кода передает больше данных, чем фактически используется (библиотеки db, плохо написанные запросы, выберите * и т.д.).

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

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

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

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

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

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