Подключить запрос или подзапрос

Question

Существуют ли правила для разработчиков, когда следует использовать объединение вместо подзапроса или они одинаковы.

Answer 1

В зависимости от РСУБД. Вы должны сравнить планы выполнения для обоих запросов.

В моем опыте с Oracle 10 и 11 планы выполнения всегда одинаковы.

Answer 2

Теоретически каждый подзапрос можно изменить на запрос соединения.

Answer 3

Производительность, они не имеют никакой разницы в большинстве современных двигателей БД.

Answer 4

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

Если возможно, всегда старайтесь делать JOIN-запросы и фильтровать с помощью предложения ON вместо WHERE (хотя он должен быть таким же, как для этого оптимизированы современные двигатели).

Answer 5

Как и во многих вещах, все зависит. - насколько сложным является подзапрос - в запросе, как часто выполняется подзапрос

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

позаботятся, Alex

Answer 6

В SQL Server коррелированный подзапрос, как правило, работает хуже, чем присоединиться или, часто даже лучше для производительности, объединение к производной таблице. Я почти никогда не пишу подзапрос для всего, что нужно будет выполнять несколько раз. Это связано с тем, что коррелированные подзапросы часто в основном превращают ваш запрос в курсор и запускают по одной строке за раз. В базах данных, как правило, лучше делать что-то по-старому.

Answer 7

Давайте проигнорируем влияние производительности на данный момент (как и следовало бы, если бы мы знали, что «Преждевременная оптимизация - корень всего зла»).

Выберите, что выглядит более понятным и удобным в обслуживании.

Answer 8

Первый принцип: «Правильно указать запрос». Второй принцип заключается в том, что «просто и явно указывать запрос» (именно там вы обычно делаете выбор). Третий - «указать запрос, чтобы он работал эффективно».

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

Мое самое большое разочарование в связи с использованием MySQL в первый раз заключалось в том, насколько я должен был осознавать оптимизатор. После долгого опыта работы с Oracle, SQL Server, Informix и другими продуктами dbms, я очень редко ожидал, что буду заниматься такими проблемами. Сейчас лучше с более новыми версиями MySQL, но мне все же приходится уделять внимание чаще, чем другим.