Каким образом работает JOIN (базы данных)?

Оно такое ВЖУХ и работает.

но оно же срабатывает без декартового произведения таблиц (как cross join)

Декартово произведение – это про результат.
Результат INNER JOIN не является декартовым произведением (без вырожденного случая со всегда истинным ON).

• INNER JOIN – пересечение
• LEFT OUTER JOIN – объединение

Есть ещё экзотический CROSS JOIN. Не пользовался.

Тут я могу посоветовать обратиться даже не к Википедии, а к англо-русскому словарю:

• INNER JOIN – внутреннее соединение;
• LEFT OUTER JOIN – левое внешнее соединение;
• INTERSECT – пересечение;
• UNION – объединение;
• CROSS JOIN – перекрёстное соединение.

в on – условие соединения. Вы про что спросить хотели?

Ух ты! Паду программистом стану. Бубу вжухать1 гыыыыыы

Я просто хочу понять как inner join сравнивает строки. Вот к примеру работа без join:

select * from t1, t2 where t1.key_t2 = t2.key

Запрос(выше) сначала выполнит все до where: сделает перемножение строк первой таблицы на вторую. Далее where отсеивает записи не удовлетворяющие условию. Производительность такого запроса низкая (если в каждой таблице миллиарды строк) из за этого перемножения.

Следующие запрос вернет тот же результат.

select * from t1 join t2 on t1.key_t2 = t2.key

Вот тут у меня и возник вопрос: как работает ON? Мое предположение(т.е сразу сравниваем без предварительного перемножения):

Строка 1 из t1 = Строка 1 из t2
Строка 1 из t1 = Строка 2 из t2
Строка 1 из t1 = Строка 3 из t2
...
Строка 2 из t1 = Строка 1 из t2
Строка 2 из t1 = Строка 2 из t2
Строка 2 из t1 = Строка 3 из t2
...

В Mysql же нет inner join?

Нет. Планировщик сделает план запроса, который и бубет выполнен. Для on и wheree планы запросов будут одинаковы. Хочеш узнать, как работает запрос, посмотри его план.

Тогда вообще непонятно зачем нужен inner join если результат будет как

select * from t1, t2 where t1.key_t2 = t2.key

Чтобы отделить условия джойна от доп. условий. Синтаксический сахарок.

Если есть индекс, он отсечет заведомо нестыкуемые варианты. Если нет, то тупо перебор.

Правильная последовательность join-ов позволяет сформировать более быстрый план запроса, т.е. эффективна при соединении 3 и более больших таблиц.

Правильная последовательность join-ов позволяет сформировать более быстрый план запроса, т.е. эффективна при соединении 3 и более больших таблиц.

Это верно только для СУБД с убогим оптимизатором запросов.

К примеру, в современном оракле эквивалентные запросы через exists и через in дадут одинаковый план запроса. В старом оракле это было не так.

Если есть индекс, он отсечет заведомо нестыкуемые варианты. Если нет, то тупо перебор.

Оптимизатор может проигнорировать индекс.

Синтаксический сахарок.

Скорее семантический. JOIN для relations, а две таблицы – это просто две таблицы.

Вообще, рассматривать JOIN в отрыве от связей – фиговый подход. Первооснова как раз таки связи. И от них уже стоит идти. А бесконечные варианты получить один и тот же результат разными способами тоже фигня. Способ есть всего один – лучший для конкретного случая. С учётом всего.

Способ есть всего один – лучший для конкретного случая.

бывает что ситуация меняется, к примеру с ростом таблиц