Когда лучше несколько запросов вместо нескольких соединений?

Question

В SO много похожих вопросов типа «Несколько запросов против одного запроса».
Но я не видел ни одного с общим выводом, поэтому я все еще смущен этим.

Итак, я спрошу об этом другими словами:

Когда лучше запускать несколько запросов вместо одного запроса с несколькими объединениями?

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

Я имею в виду, например, случаи, когда у вас есть 10+ объединений, и некоторые из этих объединений имеют отношение "многие ко многим", поэтому ваш последний запрос содержит GROUP_CONCAT, сочетание соединений LEFT и INNER и т. Д.1012 *

Например, вам нужно имя продукта 1015 *, а также все их изображения , а также все их теги , а также все их videos , а также все направления , где вы можете его купить.
Лучше сделать очень длинный запрос со сложными объединениями и group_concat (которым во многих случаях действительно сложно управлять, если выне может использовать различные) или выполнение запроса сведений о продукте, запроса изображений, другого запроса тегов и т. д. *

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

, а также в тех случаях, когда лучше выполнять несколько запросов SELECT:
быстрее выполнять их внутри транзакции(autocommit = false)?
быстрее объединить эти множественные выборки в одном запросе с несколькими вложенными выборками?

Спасибо!

Answer 1

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

Один раз у меня был запрос, который по отдельности произвел около 10 мг переданных данных, но с внутренними объединениями произвел 900 мегабайт данных, загруженных из-за повторения полей,много раз.Программное обеспечение потратило 80% своего времени, просто загружая результаты запроса.Именно здесь в игру вступает профилирование программного обеспечения, которое подскажет вам, где в своем программном обеспечении вы проводите больше всего времени.

Answer 2

Я бы сказал, что вы должны присоединиться, а не выполнять отдельные операции выбора, когда вам нужны все связанные данные одновременно, ИЛИ если связанные данные действительно большие (например, большие объекты с изображениями ...).

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

Answer 3

«Это зависит», честно говоря, единственный верный ответ. Существует и не может быть строгого правила «если больше, чем X, то разбить его». (Если бы это было так, то X должен был бы меняться каждые несколько лет. Материал, который я пишу сегодня, вероятно, затормозил бы средний сервер 10 лет назад.)

С учетом вышесказанного, лучший инструмент для определения этой точки отсечения - опыт. Чем больше вы пишете, тестируете и экспериментируете с кодом, CROSS JOIN, тем больше вы знакомы с оборудованием и наборами данных, с которыми вам нужно работать «сейчас», тем лучше вы сможете писать оптимальные запросы. Это абсолютно не означает, что только гуру, которые насмехаются над расширениями стандартов SQL-92, могут писать оптимальные запросы. При разумных усилиях новые программисты могут создавать код, который «достаточно хорош» и, как следует из названия, в целом достаточно для большинства задач.

Answer 4

Where is the limit? when a single query with Joins is worst than multiple queries?

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

Просто выбрать порядок обработки таблиц можно в N!пути, где N - количество запрашиваемых таблиц.С 5 таблицами есть 120 способов, с 10 таблицами колоссальные 3628800. И это только одно из решений, которые должен принять оптимизатор.

Answer 5

Где предел? когда один запрос с объединениями хуже, чем несколько запросов?

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

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

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