Форум программистов «Весельчак У»
  *
Добро пожаловать, Гость. Пожалуйста, войдите или зарегистрируйтесь.
Вам не пришло письмо с кодом активации?

  • Рекомендуем проверить настройки временной зоны в вашем профиле (страница "Внешний вид форума", пункт "Часовой пояс:").
  • У нас больше нет рассылок. Если вам приходят письма от наших бывших рассылок mail.ru и subscribe.ru, то знайте, что это не мы рассылаем.
   Начало  
Наши сайты
Помощь Поиск Календарь Почта Войти Регистрация  
 
Страниц: [1]   Вниз
  Печать  
Автор Тема: Prepared Query VS Stored Procedure  (Прочитано 604 раз)
0 Пользователей и 1 Гость смотрят эту тему.
..::SCRIBE::..
Помогающий

ua
Offline Offline
Пол: Мужской
не путайте банальность с ленью=)


« : 12-11-2017 23:06 » 

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

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

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

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

Спасибо за будущие ответы Улыбаюсь
Записан
Sla
Команда клуба

ua
Offline Offline
Пол: Мужской

WWW
« Ответ #1 : 13-11-2017 01:13 » 

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

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

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

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

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

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

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





Записан

Мы все учились понемногу... Чему-нибудь и как-нибудь.
RXL
Технический
Администратор

ru
Offline Offline
Пол: Мужской

WWW
« Ответ #2 : 13-11-2017 07:18 » 

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

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

... мы преодолеваем эту трудность без синтеза распределенных прототипов. (с) Жуков М.С.

Хз, я не очень просто не очень во всё это верю, во всякие там сатурны и прочую поебень.
..::SCRIBE::..
Помогающий

ua
Offline Offline
Пол: Мужской
не путайте банальность с ленью=)


« Ответ #3 : 13-11-2017 21:19 » 

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

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

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

Привязка к конкретной СУБД даст больше минусов, чем даст плюсов использование ее фишек.
Для такого вида софта никто не будет использовать что-то лучше/надежней/дороже/брендовей, нужное подчеркнуть))
Оно будет точно и всегда на мускуле, и хочется выжать из него максимум.
Записан
..::SCRIBE::..
Помогающий

ua
Offline Offline
Пол: Мужской
не путайте банальность с ленью=)


« Ответ #4 : 13-11-2017 21:24 » 

Насчет кэширования.
Пишут, что кэшируется тело.
Цитата
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
Технический
Администратор

ru
Offline Offline
Пол: Мужской

WWW
« Ответ #5 : 13-11-2017 22:14 » 

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

... мы преодолеваем эту трудность без синтеза распределенных прототипов. (с) Жуков М.С.

Хз, я не очень просто не очень во всё это верю, во всякие там сатурны и прочую поебень.
..::SCRIBE::..
Помогающий

ua
Offline Offline
Пол: Мужской
не путайте банальность с ленью=)


« Ответ #6 : 13-11-2017 22:28 » 

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

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

ru
Offline Offline
Пол: Мужской

WWW
« Ответ #7 : 13-11-2017 22:36 » 

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

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

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

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

... мы преодолеваем эту трудность без синтеза распределенных прототипов. (с) Жуков М.С.

Хз, я не очень просто не очень во всё это верю, во всякие там сатурны и прочую поебень.
..::SCRIBE::..
Помогающий

ua
Offline Offline
Пол: Мужской
не путайте банальность с ленью=)


« Ответ #8 : 13-11-2017 22:46 » 

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

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

ua
Offline Offline
Пол: Мужской
не путайте банальность с ленью=)


« Ответ #9 : 13-11-2017 22:50 » new

Активность пользователей имеет свои пики, так что временная недоступность не страшна.
Записан
Страниц: [1]   Вверх
  Печать  
 

Powered by SMF 1.1.21 | SMF © 2015, Simple Machines