Сколько запросов MySQL я должен ограничить на странице? PHP / MySQL - PullRequest
13 голосов
/ 18 февраля 2009

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

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

  • содержание статьи и информация
  • ЕСЛИ автор является зарегистрированным пользователем, его информация
  • ОБНОВЛЕНИЕ счетчика просмотров статьи
  • получить комментарии к статье
  • поиск информации для авторов комментариев
  • если читатель статьи вошел в систему, запросить информацию о них
  • и т.д ...

Я знаю, что в основном это будет довольно быстро, и я мог бы объединить некоторые; но я хотел убедиться, что это не ненормально?

Сколько довольно обычных и несложных запросов вы бы ограничили на странице?

Ответы [ 10 ]

29 голосов
/ 18 февраля 2009

Столько, сколько нужно, но не больше.

Действительно: не беспокойтесь об оптимизации (прямо сейчас). Сначала создайте его, затем измерьте производительность, и IFF где-то есть проблема с производительностью, затем начните с оптимизации.

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

8 голосов
/ 18 февраля 2009

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

Если страница загружается менее чем за 200 мс, у вас будет быстрый сайт. Большая часть этого используется задержкой между вашим сервером и браузером, поэтому я хотел бы стремиться к <100 мс времени, проведенного на сервере. Сделайте столько запросов, сколько вы хотите в этот период времени. </p>

Вероятно, большим узким местом будет количество времени, которое вам придется потратить на проект, поэтому сначала оптимизируйте его :) Оптимизируйте код позже, если потребуется. При этом, если вы собираетесь написать какой-либо код, связанный с этой проблемой, напишите что-нибудь, что сделает очевидным, сколько времени занимают ваши запросы. Таким образом, вы можете, по крайней мере, узнать, что у вас есть проблема.

5 голосов
/ 18 февраля 2009

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

Если он работает на том же хосте, все равно будет небольшое снижение скорости, не только потому, что сокет находится между вашим приложением, но также и потому, что сервер должен проанализировать ваш запрос, создать ответ, проверить доступ и все остальное, что накладывает ваши расходы. получил с SQL-серверами.

Так что в целом лучше иметь меньше запросов.

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

Ответ Писквора по-прежнему применим в любом случае.

5 голосов
/ 18 февраля 2009

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

2 голосов
/ 18 февраля 2009

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

Обычно указание на то, что вы делаете что-то не так, это когда у вас есть SQL внутри цикла.

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

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

2 голосов
/ 18 февраля 2009

Wordpress, например, может тянуть до 30 запросов на страницу. Есть несколько вещей, которые вы можете использовать, чтобы остановить MySQL - одна из них - memchache - но прямо сейчас и, как вы говорите, если это будет просто, просто убедитесь, что все извлекаемые вами данные правильно проиндексированы в MySQL и не волнуйтесь много о количестве запросов.

Если вы используете Framework (например, CodeIgniter), вы обычно можете получить данные за время создания страницы и проверить, что тянет ваш сайт вниз.

1 голос
/ 11 апреля 2009

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

1 голос
/ 19 февраля 2009

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

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

1 голос
/ 18 февраля 2009

Если вам нужны запросы, вы должны просто использовать их.

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

0 голосов
/ 19 февраля 2009

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

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

Добро пожаловать на сайт PullRequest, где вы можете задавать вопросы и получать ответы от других членов сообщества.
...