MySQL: Сколько запросов на странице слишком много?

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

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

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

Буду признателен за любые мнения по этому поводу.

Спасибо

Ответ 1

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

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

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

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

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

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

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

Ответ 2

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

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