Ключевые слова INNER JOIN | с использованием и без использования

SELECT * FROM TableA
INNER JOIN TableB
ON TableA.name = TableB.name

SELECT * FROM TableA, TableB
where TableA.name = TableB.name

что предпочтительней и почему? Будет ли разница в производительности при использовании таких ключевых слов, как JOIN?

спасибо

8
join sql

6 ответов

второй способ-это классический способ сделать это, перед join ключевое слово существовало.

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

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

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

11

используйте первый, как он есть:

  • более явный
  • является стандартным способом

Что касается производительности - не должно быть никакой разницы.

3

узнайте, с помощью EXPLAIN SELECT …

Это зависит от используемого движка, оптимизатора запросов, ключей, таблицы; практически от всего

1

в некоторых SQL двигателей вторая форма (ассоциативных соединений) является depreicated. Используйте первую форму.

второй менее явный, заставляет begginers SQL приостанавливаться при написании кода. Гораздо сложнее управлять в сложном SQL из-за последовательности требования соответствия соединения, чтобы соответствовать последовательности предложения WHERE - они (squence в коде) должны совпадать или возвращаемые результаты изменятся, что приведет к изменению возвращаемого набора данных, который действительно идет против мысли, что последовательность не следует изменять результаты при рассмотрении элементов на одном уровне.

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

EDIT: Performance: я считаю кодирование, отладку легкой частью личной производительности, поэтому простота редактирования / отладки/обслуживания лучше работает с использованием первой формы - мне просто требуется меньше времени, чтобы сделать / понять материал во время разработки и обслуживания циклы.

1

большинство текущих баз данных оптимизируют оба этих запроса в один и тот же план выполнения. Однако используйте первый синтаксис, это текущий стандарт. Изучая и используя этот синтаксис соединения, он поможет при выполнении запросов с LEFT OUTER JOIN и RIGHT OUTER JOIN. которые становятся сложными и проблематичными, используя старый синтаксис с соединениями в предложении WHERE.

0

фильтрация объединяется исключительно с использованием WHERE может быть крайне неэффективной в некоторых распространенных сценариях. Например:

SELECT * FROM people p, companies c WHERE p.companyID = c.id AND p.firstName = 'Daniel'

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

A лучший подход-сгруппировать ограничения с объединениями, где это уместно. Это не только субъективно легче читать, но и гораздо более эффективными. Так:

SELECT * FROM people p JOIN companies c ON p.companyID = c.id
    WHERE p.firstName = 'Daniel'

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

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

0