Кол-во запросов к MySQL

Question

[Snewer]

Здравствуйте!

Какие оптимальное кол-во запросов за одно выполнение скрипта к базе данных считается хорошим тоном? В общих чертах, обычные запросы выборки. Спасибо.

Answer 1

[Андрей Унгер]

Нет такого понятия как оптимальное число запросов. Правило одно - чем меньше, тем лучше. По хорошему лучше всего даже вообще не делать запросы к БД а вытаскивать данные например из мемкеша. Т.е. если данные не часто обновляются, то лучше их закэшировать при первом запросе и отдавать кэш. Основной концепт - производительность.

Comments

[Snewer]

Хотелось бы узнать среднее кол-во запросов в проектах которые реально работают и процветают

[Андрей Унгер]

Эм, а зачем? Это как узнать площадб сферического коня в вакуме. Толку вам от этого числа? Все зависит от того где и как они применяются. Если у вас главная страница вызыват 100+ запросов - это явно неверно. Но если эти же 100+ запросов вызывает скрипт периодически запускаемый по крону в 12 часов ночи - вполне приемлемо.

[Андрей Унгер]

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

[svd71]

@Snewer, @Cobalt прав. Это зависит от многих параметров: производительности сервера базы, сложности структуры базы размера таблиц данных в каждой конкретной выборке.
Итоговым является общее время испольнения скрипта. Всякие реализации в виде мемкэшей не всегда нужное решение. Некоторые СУБД имеют некоторые механизмы кэширования данных. Например firebird данные хранит в страницах и требуемые страницы не сразу освобождаются из памяти, а по мере надобности памяти. Это ведет к тому, что при получении повторного запроса на обработку время исполнения значительно уменьшится.
От себя замечу, что куча мелких запросов к куче таблиц работает чаще намного шустрее и менее напряжнее для нагрузки СУБД, чем один суперзапрос с кучей данных и агрегированных значений.

[Андрей Никитин]

Андрей Унгер, добрый день, знаю, что много времени прошло, но может ответите)) Пишу проект на Yii2, обычный блог со статьями. На главной странице, 25 запросов к БД, время 180ms и memory 8.5 mb. Это нормально? Просто уже все закешировал, а все равно какие то запросы летят, типа связь между таблицами. Вот думаю, оставить так, или вылизывать до того момента, пока будет 1-2 запроса или вообще ноль

Answer 2

[Пума Тайланд]

Ни одного.

Comments

[Snewer]

смешно

[Пума Тайланд]

Для быстрого сайта с хорошей посещалкой это хороший тон, все просто отдать из кеша и не сделать ни одного запроса в базу.

[Snewer]

@opium В таком случае лучше уж использовать не реляционные бд

[Snewer]

Все данные в кеш не засунуть

[Пума Тайланд]

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

Answer 3

[WhoMe]

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

Answer 4

[Виталий Желтяков]

Лично я стремлюсь к следующему:
- Простое действие - 1 запрос;
- Вывод списка - количество запросов равно числу членов списка.
Но это в идеале.

Comments

[Александр Зеленин]

select * from users даст список одним запросом.

[Виталий Желтяков]

@zelenin А fetch?

[Александр Зеленин]

@VitaZheltyakov что fetch?

[Виталий Желтяков]

@zelenin select получает объект выборки, а чтобы получить данные из этой выборки нужно выполнить fetch. fetch тоже обращается к базе в рамках выборки. Соответственно, чем больше строк тем больше fetch, тем больше обращений к базе.

[Александр Зеленин]

@VitaZheltyakov в моем мире fetch преобразовывает ресурс, полученный в ходе запроса, в удобоваримый в PHP вид (массив, объект).

Answer 5

[Максим Углов]

В зависимости от выполняемой задачи. Если интересно на практике то поставьте любую CMS и в функции обращения к базе сделайте вывод запроса или подсчет их количества.

У меня вышло для моего самописного движка - 7 запросов
Движок доски объявлений - 13 запросов
WordPress - 13 запросов

Количество запросов важно поскольку много времени уходит на подготовительную процедуру запроса. Лучше сделать один запрос с дополнительными данными чем 3 которые эти данные будет дополнять.

Comments

[Rpsl]

>> Количество запросов важно поскольку много времени уходит на подготовительную процедуру запроса. Лучше сделать один запрос с дополнительными данными чем 3 которые эти данные будет дополнять.

wat?

[Максим Углов]

select * from post left join users on users.id=post.user_id where id='123'
лучше чем
select * from post where id='123'
и
select * from users where id='{post["user_id"]}'

Answer 6

[demimurych]

Парадигма - меньшее количество запросов = лучше не всегда является верной. Потому как далеко не всегда один большой запрос выполняется быстрее чем три более простых.
В силу вступает очень много разных факторов, от типов запросов типов таблиц, до того каким образом организовано общение с сервером. Тот же mysql можно использовать как key value хранилище не уступающее в производительности другим решениям в этой области.