Prepared Query VS Stored Procedure

[SCRIBE]

Всем привет.
Давно не виделись 

Используется PHP/PDO.

Собственно, что лучше(быстрее) для MySQL сервера?
Логика позволяет использовать и то, и то.

Лично я за Stored Procedure, ибо вычитал что они кэшируются.
Но возможно есть подвоные камни, у кого какие идеи?

Спасибо за будущие ответы

[Sla]

в последнее время столько развелось веток mysql, что уследить достаточно сложно, если самостоятельно этим не заниматься.

Цели и задачи?

Для ведения логов? MyIsam
Для критичных транзакций - Innodb

У других веток, есть свои типы таблиц, которые чем-то в чем-то лучше, но где-то хуже, например полнотекстовый индекс.

StoredProcedure - что кешируется? Может просто оно хранятся в уже разобранном виде и не требуется время на компиляцию

Быстрее?
Количество запросов?
Размер выборки?
Наличие агрегатных запросов?
Количество joinутых таблиц
Наличие индексов, как простых так и составных

А почему не представления? view

[RXL]

Собственно, что лучше(быстрее) для MySQL сервера?

Грамотно сделанная база даст больше профита.
Привязка к конкретной СУБД даст больше минусов, чем даст плюсов использование ее фишек.

[SCRIBE]

Дам некоторые ответы, интересуют 2 таблички:
1. Для ведения учета сессий в БД (в основном SELECT/UPDATE).
2. Для вытягивания некоторой инфы через АПИ, частота... макс 5 тыс. пользователей которые делают запрос раз в 4-5 мин. Тоже SELECT/UPDATE.

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

Грамотно сделанная база даст больше профита.

Структура более менее проповедуюет правильные формы.

Привязка к конкретной СУБД даст больше минусов, чем даст плюсов использование ее фишек.

Для такого вида софта никто не будет использовать что-то лучше/надежней/дороже/брендовей, нужное подчеркнуть))
Оно будет точно и всегда на мускуле, и хочется выжать из него максимум.

[SCRIBE]

Насчет кэширования.
Пишут, что кэшируется тело.

Stored programs (stored procedures and functions, triggers, and events). In this case, the server converts and caches the entire program body. The stored_program_cache system variable indicates the approximate number of stored programs the server caches per session.

https://dev.mysql.com/doc/refman/5.6/en/statement-caching.html

Хотя дальше опечалили...

The server maintains caches for prepared statements and stored programs on a per-session basis. Statements cached for one session are not accessible to other sessions. When a session ends, the server discards any statements cached for it.

Сессия, я так понимаю, это время пока скрипт на PHP выполняется, в смысле пока жив объект PDO?

[RXL]

При чем тут брендовость и цена? Не только лишь один MySQL доступен из open source. PostgreSQL вполне себе быстр.
Одно время на работе использовали MyISAM как хранилище key-value: очень быстр при условии полного кеширования индекса, но ненадежен. Позже по нашим тестам Posgresql 9.4 сравнялся с MyISAM, при этом имеет полный фарш возможностей. Еще есть MariaDB: наследует особенности MyISAM, но имеет лог для восстановления целостности (скорость не проверял).

[SCRIBE]

Мало пользовал Postgre... Наверное все же со временем придется сделать какие-то сравнительные тесты, а так лень...))

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

[RXL]

В PHP есть постоянные соединения. Получается пул соединений. Это смотри в доке PHP PDO.

Prepared statement я бы тут использовать не стал, т.к. после подключения нужно знать, был ли уже создан твой prepared statement или нет. Точнее нужно читать в доке MySQL.

Stored procedure штука гибкая, но сомневаюсь, что это добавит скорости. Пропарсенный код кешируется в памяти, живет до перезагрузки сервера.

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

[SCRIBE]

Спасибо большое за ответы.

Буду ковырять в сторону MyISAM наверно, почитал про кэшированные индексы, штука заманчивая...
Ну и процедуры, да, мне они тоже по душе, и код чище...

[SCRIBE]

Активность пользователей имеет свои пики, так что временная недоступность не страшна.