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

Ответ 1

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

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

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

Ответ 2

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

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

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

Ответ 3

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

Ответ 4

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

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

В общем, лучше иметь меньше запросов.

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

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

Ответ 5

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

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

Ответ 6

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

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

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

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

Ответ 7

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

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

Ответ 8

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

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

Ответ 9

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

Ответ 10

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

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