Каков оптимальный номер запроса MYSQL в скрипте php?

Question

Я не профессиональный программист, поэтому не могу быть в этом уверен. Сколько запросов mysql отправляют ваши скрипты на одной странице и каков ваш оптимальный номер запроса. Например, на домашней странице stackoverflow в нем перечислены вопросы, на которых указаны авторы этих вопросов. Это stackoverflow отправляет MySQL запрос на каждый вопрос, чтобы получить информацию об авторе. или он отправляет 1 запрос, получает все данные пользователя и сопоставляет его с вопросами?

Answer 1

Мне нравится держать мой под 8.

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

Медленные запросы важнее

Раньше я был разочарован в некотором программном обеспечении для форумов на основе PHP, которое выполняло 35 запросов на странице и выполнялось очень медленно, но это было давно, и теперь я знаю, что причина, по которой конкретная установка выполнялась медленно, не имела ничего общего с 35 запросов на странице. Например, только один или два из этих запросов заняли большую часть времени. У него была пара действительно медленных запросов, которые были исправлены с помощью правильно размещенных индексов.

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

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

Попробуйте кешировать

Существуют различные способы кэширования частей вашего приложения, которые действительно могут сократить количество запросов, которые вы выполняете, без снижения функциональности. Такие библиотеки, как memcached , в наши дни упрощают эту задачу, но при этом работают очень быстро. Это также может помочь повысить производительность намного больше, чем уменьшить количество запросов.

Если запросы действительно не нужны и производительность действительно имеет значение, то удалите / объедините их

Просто сначала подумайте о поиске медленных запросов и их оптимизации или кэшировании их результатов.

Answer 2

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

• сколько запросов дублируется?
• сколько запросов имеют пересекающиеся наборы данных? или подмножество другого?
• как долго они бегут? Вы профилировали общие для проверки индексов?

• сколько излишне сложных?

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

• сколько прогрессивной обработки вы делаете?

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

• сколько вы можете кэшировать некоторые из этих данных? Даже кэширование в течение нескольких секунд может очень помочь.

Answer 3

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

В некоторых случаях это заставляло страницу загружаться значительно быстрее.

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

Answer 4

Там действительно нет оптимального количества запросов. Очевидно, что чем меньше запросов вы сделаете, тем лучше.

Если вы используете какой-либо ORM, такой как Hibernate, Propel, Doctrine и т. Д., Они будут генерировать запросы иначе, чем если бы вы писали SQL вручную. Поэтому, если StackOverflow использует ORM, у них может быть несколько запросов на доступ к вопросам и пользователям, создавшим вопросы. Или они могут просто использовать соединение с прямым SQL.

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

Вещи, которые вы должны исследовать, чтобы лучше понять это:

• Ленивая загрузка
• реляционное отображение объектов

Answer 5

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

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

Answer 6

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

Когда я впервые установил WordPress, я был потрясен, что при базовой установке было выполнено более 20 запросов! Плагины увеличат это число (некоторые совсем немного). Но с кешированием это может быть сведено к нулю (SuperCache). Если ваш контент меняется каждые 10 минут, зачем генерировать его динамически при каждом попадании?

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

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

Answer 7

Столько, сколько вам нужно, и не более. Здесь нет практического правила. Некоторые сайты требуют большого количества доступа к БД, а другие нет.

Так что на самом деле есть только несколько вызовов дб, если написано так, как я думаю. На такой странице, как ответ на вопрос, будет:

1) проверка сеанса, если вы вошли в систему. 2) текущая информация о пользователе, чтобы получить панель пользователя в верхней части экрана и подсчет медалей. 3) получить информацию о вопросе, а также информацию о вопроснике / последнем редакторе. 4) получить количество тегов, использованных в этом вопросе. 5) выберите все ответы и данные респондента за один снимок.

И это все. Самое интересное в том, сколько всего от этого зависит:

// this returns one row per revision
select q.*, u.name, u.u_id, u.points, u.gmedal, u.smedals, u.bmedals
from questions q left outer join users on q.u_id = u.u_id
where q_id = :q_id;

// this used to display the tags below the question and the tag counts on the right
select t.name, count(*)
from tags t left join tags q on q.tagid = t.tagid
where t.q_id = :q_id

// this can also get multiple revisions
select a.*, u.name, u.u_id, u.points, u.gmedal, u.smedals, u.bmedals
from answers a left outer join users on a.u_id = u.u_id
where a.q_id = :q_id

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

Answer 8

0 будет оптимальным, если вы задаете приоритет скорости.