INNER JOIN ключевые слова | с и без их использования - PullRequest
8 голосов
/ 16 апреля 2010
SELECT * FROM TableA
INNER JOIN TableB
ON TableA.name = TableB.name

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

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

Спасибо

Ответы [ 6 ]

11 голосов
/ 16 апреля 2010

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

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

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

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

3 голосов
/ 16 апреля 2010

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

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

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

1 голос
/ 16 апреля 2010

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

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

Когда создаются объединения, содержащие несколько таблиц, код ДЕЙСТВИТЕЛЬНО становится трудно кодировать, довольно быстро используя вторую форму.

РЕДАКТИРОВАТЬ: Производительность: я считаю, что кодирование, отладка - это часть личной работы, поэтому удобство редактирования / отладки / сопровождения лучше выполнять с помощью первой формы - мне просто требуется меньше времени, чтобы делать / понимать вещи во время разработки и обслуживания циклы.

1 голос
/ 16 апреля 2010

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

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

0 голосов
/ 21 декабря 2016

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

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

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

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

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

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

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

0 голосов
/ 16 апреля 2010

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

Добро пожаловать на сайт PullRequest, где вы можете задавать вопросы и получать ответы от других членов сообщества.
...