Каким количеством запросов MySQL я должен ограничить меня на странице? PHP / MYSQL

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

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

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

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

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

14
задан Logan Besecker 19 October 2012 в 22:39
поделиться

10 ответов

Как многие по мере необходимости, но не больше.

В самом деле: не волнуйтесь об оптимизации (прямо сейчас). Создайте его сначала, измерьте второй уровень, и ЭКВИВАЛЕНТНОСТЬ, там проблема производительности где-нибудь, затем запустите с оптимизации.

Иначе Вы рискуете проводить много времени на оптимизации чего-то, чему не нужна оптимизация.

30
ответ дан 1 December 2019 в 06:07
поделиться

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

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

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

8
ответ дан 1 December 2019 в 06:07
поделиться

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

5
ответ дан 1 December 2019 в 06:07
поделиться

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

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

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

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

Ответ Piskvor все еще применяется в любом случае.

5
ответ дан 1 December 2019 в 06:07
поделиться

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

При использовании Платформы (CodeIgniter, например), можно обычно вытягивать данные в течение времен создания страницы и проверять то, что раскрывает сайт.

2
ответ дан 1 December 2019 в 06:07
поделиться

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

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

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

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

2
ответ дан 1 December 2019 в 06:07
поделиться

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

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

1
ответ дан 1 December 2019 в 06:07
поделиться

При необходимости в запросах необходимо просто использовать их.

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

1
ответ дан 1 December 2019 в 06:07
поделиться

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

1
ответ дан 1 December 2019 в 06:07
поделиться

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

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

0
ответ дан 1 December 2019 в 06:07
поделиться
Другие вопросы по тегам:

Похожие вопросы: