Накладные расходы для MySQL SELECTS — лучше использовать один или несколько последовательно

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

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

Лично мне нравится выполнять сложные SQL-запросы, но я обнаружил, что размер таблиц, кеш запросов mysql и производительность запросов, которые должны выполнять проверку диапазона (даже по индексу), имеют значение.

Я предлагаю это:

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

2) Закодируйте сложный запрос. Сравните результаты на точность, а затем на время. Затем используйте EXPECT в запросе, чтобы увидеть, какие строки отсканированы. Я часто обнаруживал, что если у меня есть JOIN, или WHERE x != y, или условие, создающее временную таблицу, производительность запроса может сильно ухудшиться, особенно если я нахожусь в таблице, которая постоянно обновляется. Однако я также обнаружил, что сложный запрос может быть неправильным, а также что сложный запрос может легко сломаться по мере роста приложения. Сложные запросы обычно сканируют большие наборы строк, часто создают временные таблицы и вызывают using where сканирование. Чем больше стол, тем дороже они получаются. Кроме того, у вас могут быть групповые соображения, когда сложные запросы не соответствуют сильным сторонам вашей команды.

3) Поделитесь результатами со своей командой.

Сложные запросы с меньшей вероятностью попадут в кеш запросов mysql, и если они достаточно велики, не кэшируйте их. (Вы хотите сохранить кеш запросов mysql для часто попадающихся запросов.) Кроме того, запрос, где предикаты, которые должны сканировать индекс, также не будут работать. (х != у, х > у, х ‹ у). Такие запросы, как SELECT foo, bar FROM users WHERE foo != 'g' and mumble < '360', заканчиваются сканированием. (Стоимость накладных расходов на запросы в этом случае может быть незначительной.)

Небольшие запросы часто можно выполнять без создания временных таблиц, просто получая все значения из индекса, если поля, которые вы выбираете и на которых основываетесь, индексируются. Таким образом, производительность запросов SELECT foo, bar FROM users WHERE id = x действительно велика (особенно, если столбцы foo и bar индексируются, например, alter table users add index ix_a ( foo, bar );.)

Другими хорошими способами повышения производительности вашего приложения могут быть кэширование этих небольших результатов запроса в приложении (если это уместно) или выполнение пакетных заданий запроса материализованного представления. Кроме того, рассмотрите memcached или некоторые функции, имеющиеся в XCache.

Кажется, вы знаете, что такое 500 значений id, так почему бы не сделать что-то вроде этого:

// Assuming you have already validated that this array contains only integers
// so there is not risk of SQl injection

$ids = join(',' $arrayOfIds);

$sql = "SELECT `foo`, `bar` FROM `users` WHERE `id` IN ($ids)";