MySQL объединяет записи из двух таблиц с объединением и без

Question

В чем разница между этими двумя запросами:

SELECT `threads`.`id` AS `threads.id` , `posts`.`id` , `posts`.`content`
FROM `threads`
JOIN `posts` ON `threads`.`id` = `posts`.`thread_id`

И

SELECT `threads`.`id` AS `threads.id` , `posts`.`id` , `posts`.`content`
FROM `threads` , `posts`
WHERE `threads`.`id` = `posts`.`thread_id`

Они оба возвращают одни и те же данные.

Answer 1

WHERE набор результатов фильтрации предложений, который возвращается JOIN, так что это разница.

Пока вы используете INNER JOIN, нет различий ни по производительности, ни по плану выполнения, в случае любого запроса OUTER JOIN будет получен другой план выполнения.

Также обратите внимание на то, чтосказано в MySql online doc :

Как правило, вы должны использовать предложение ON для условий, которые определяют, как объединять таблицы, и предложение WHERE, чтобы ограничивать, какие строки вы хотитев наборе результатов.

Answer 2

Одним словом: удобочитаемость.

Выполнение следующего кода:

create table #threads (
id int
)

create table #posts (
id int,
thread_id int,
content varchar(10)
)

insert into #threads values (1)
insert into #threads values (2)
insert into #posts values (1, 1, 'Stack')
insert into #posts values (2, 2, 'OverFlow')


SELECT #threads.id AS 'threads.id' , #posts.id , #posts.content
FROM #threads
JOIN #posts ON #threads.id = #posts.thread_id

SELECT #threads.id AS 'threads.id' , #posts.id , #posts.content
FROM #threads, #posts
WHERE #threads.id = #posts.thread_id

drop table #threads
drop table #posts

в http://data.stackexchange.com/stackoverflow/query/new вы получите тот же план выполнения:)

Единственная реальная разница заключается в том, что inner join - это ANSI , а from #threads, #posts - это Синтаксис Transact-SQL.

Answer 3

Один использует соединения ANSI, другой использует соединение в стиле до ANSI. Движки MOST DB скомпилируют их в один и тот же план выполнения.

Answer 4

Может быть разница во внутренней реализации этих запросов, но я сомневаюсь в этом. Я лично предпочел бы JOIN, потому что это делает план выполнения более очевидным.