Должен ли я использовать один большой оператор SQL Select или несколько маленьких?

Question

Я создаю страницу PHP с данными, отправленными из MySQL.

Лучше иметь

• 1 SELECT запрос с 4 объединениями таблиц или
• 4 маленьких SELECT запросов без объединения таблиц; Я выбираю из ID

Что быстрее и каково за / против каждого метода? Мне нужна только одна строка из каждой таблицы.

Answer 1

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

Убедитесь, что вы фильтруете вещи так хорошо, как можете, используя предложения where и join для предложений.

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

Answer 2

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

Answer 3

Это может зависеть от того, что вы делаете с данными после извлечения их из БД. Если вы используете каждый из четырех результатов независимо, то было бы логичнее и понятнее иметь четыре отдельных оператора SELECT. С другой стороны, если вы используете все данные вместе, например, для создания единой строки в таблице или что-то в этом роде, я бы выбрал один SELECT и JOIN.

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

Answer 4

Как правило, лучше иметь один оператор SELECT. Одна из основных причин наличия баз данных заключается в том, что они быстро обрабатывают информацию, особенно если она имеет формат запроса.

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

Answer 5

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

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

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

Answer 6

Я бы сказал, 1 запрос с объединением. Таким образом, вам нужно попасть на сервер только один раз. И если ваши таблицы объединены с индексами, это должно быть быстро.

Answer 7

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