Внутреннее соединение против Где

Есть ли разница в производительности (в оракуле) между

Select * from Table1 T1 
Inner Join Table2 T2 On T1.ID = T2.ID

И

Select * from Table1 T1, Table2 T2 
Where T1.ID = T2.ID

?

Нет! Тот же план выполнения, посмотрите на эти две таблицы:

CREATE TABLE table1 (
  id INT,
  name VARCHAR(20)
);

CREATE TABLE table2 (
  id INT,
  name VARCHAR(20)
);

План выполнения запроса с использованием внутреннего соединения:

-- with inner join

EXPLAIN PLAN FOR
SELECT * FROM table1 t1
INNER JOIN table2 t2 ON t1.id = t2.id;

SELECT *
FROM TABLE (DBMS_XPLAN.DISPLAY);

-- 0 select statement
-- 1 hash join (access("T1"."ID"="T2"."ID"))
-- 2 table access full table1
-- 3 table access full table2

И план выполнения для запроса с использованием предложения WHERE.

-- with where clause

EXPLAIN PLAN FOR
SELECT * FROM table1 t1, table2 t2
WHERE t1.id = t2.id;

SELECT *
FROM TABLE (DBMS_XPLAN.DISPLAY);

-- 0 select statement
-- 1 hash join (access("T1"."ID"="T2"."ID"))
-- 2 table access full table1
-- 3 table access full table2

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

Они должны быть точно такими же. Однако, как практика кодирования, я бы предпочел увидеть Join. Это ясно выражает ваши намерения,

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

Там нет разницы в скорости ( я только что проверил ) и план выполнения такой же.

Я не знаю об Oracle, но я знаю, что старый синтаксис устарел в SQL Server и со временем исчезнет. Прежде чем использовать этот старый синтаксис в новом запросе, я проверю, что Oracle планирует с ним делать.

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

И опять же, я не знаю Oracle конкретно, но я знаю, что версия левого соединения старого стиля SQL Server имеет недостатки даже в SQL Server 2000 и дает противоречивые результаты (иногда левое соединение, иногда перекрестное соединение), поэтому никогда не следует используемый. Надеюсь, Oracle не сталкивается с той же проблемой, но, конечно, левые и правые объединения могут быть намного сложнее правильно выразить в старом синтаксисе.

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

[Для получения бонусного балла ...]

Использование синтаксиса JOIN позволяет вам легче закомментировать объединение, так как все оно включено в одну строку. Это может быть полезно, если вы отлаживаете сложный запрос

Как и все остальные, они функционально одинаковы, однако JOIN более четко выражает намерение. Поэтому он может помочь оптимизатору запросов в текущих версиях Oracle в определенных случаях (я понятия не имею, так ли это), он может помочь оптимизатору запросов в будущих версиях Oracle (никто не имеет представления) или может помочь, если Вы меняете поставщика базы данных.

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

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

Также можно избежать непреднамеренных декартовых продуктов, используя версию join.

Третий эффект - более легкий для чтения SQL с более простым условием WHERE.

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

select *
from Table1 inner join Table2 using (ID);

Это также имеет тот же план запроса, конечно.

В сценарии, где таблицы находятся в 3-й нормальной форме, соединения между таблицами не должны изменяться. Т.е. присоединяйтесь к ЗАКАЗЧИКАМ, и ОПЛАТЫ всегда должны оставаться неизменными.

Однако мы должны отличать объединения от фильтров . Объединения связаны с отношениями, а фильтры - с разделением целого.

Некоторые авторы, ссылаясь на стандарт (например, Джим Мелтон; Алан Р. Саймон (1993). Понимание нового SQL: Полное руководство. Морган Кауфманн. С. 11–12. ISBN 978-1-55860-245-8.) , писал о преимуществах применения синтаксиса JOIN над таблицами, разделенными запятыми, в предложении FROM.

Я полностью согласен с этой точкой зрения.

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

В PostgreSQL, безусловно, нет никакой разницы - они оба соответствуют одному и тому же плану запросов. Я на 99% уверен, что это касается и Oracle.

Они оба являются внутренними объединениями, которые делают одно и то же, один просто использует более новый синтаксис ANSI.

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

Это правда, что функционально оба запроса должны обрабатываться одинаково. Однако опыт показывает, что если вы выбираете из представлений, которые используют новый синтаксис объединения, важно также структурировать свои запросы, используя его. Оптимизатор Oracle может запутаться, если представление использует оператор «join», но запрос, обращающийся к представлению, использует традиционный метод объединения в предложении «where».

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

Вот почему мы не можем ответить на этот вопрос в целом, потому что это зависит от внутренних данных БД. Но мы должны знать, что ответ должен быть « без различий ».

У меня была эта загадка сегодня, когда я проверял время ожидания одного из наших sp в производственной среде, вместо этого я изменил внутреннее соединение таблицы, построенной из xml-фида, на условие 'where' .... среднее время выполнения теперь составляет 80 мс для 1000 выполнений, тогда как до того, как среднее значение exec составило 2,2 секунды ... главное отличие в плане выполнения - это исчезновение поиска ключа ... Сообщение, о котором вы не узнаете, пока не протестируете оба метода.

веселит.

Они оба присоединяются и где это делают то же самое.

Посмотрите на запросы MySQL, зачем использовать join вместо где?

Как сказал киевик, план выполнения такой же.

Оператор JOIN легче читать, так что легче не забывать условие ON и получать декартово произведение. Эти ошибки могут быть довольно трудно обнаружить в длинных запросах с использованием нескольких объединений типа: SELECT * FROM t1, t2 WHERE t1.id = t2.some_field.

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

Именно поэтому использование оператора JOIN, безусловно, является лучшей практикой: лучшая ремонтопригодность и лучшая читаемость.

Более того, если я хорошо помню, JOIN оптимизирован в отношении использования памяти.

У меня есть дополнение к этому хорошему ответу :

Это то, что определяется как SQL92 и SQL89 соответственно, между ними нет разницы в производительности, хотя вы можете опустить слово INNER (достаточно просто использовать JOIN, и в простейшем запросе вы сохраняете 5 нажатий клавиш, теперь представьте, сколько штрихов в большом из них).