Знание разницы поможет оптимизировать запросы, сократить время выполнения и избежать ошибок. Вы поймёте, почему иногда INNER JOIN выигрывает, даже если кажется обратное. Это решит проблемы с тормозами в больших таблицах.

Как работают INNER JOIN и LEFT JOIN

INNER JOIN возвращает только те строки, где есть совпадения в обеих таблицах. Он прост и эффективен, когда нужны только связанные данные. База не тратит время на несовпадающие записи — сразу отсекает их.

LEFT JOIN берёт все строки из левой таблицы и добавляет совпадения из правой, если они есть. Если совпадений нет, поля правой таблицы заполняются NULL. Это полезно, чтобы сохранить все данные слева, но может замедлить запрос из-за обработки лишних строк.

В простых случаях разница минимальна. Но с большими таблицами или удалёнными серверами INNER JOIN часто быстрее. Например, в тесте с таблицами пользователей и профилей INNER JOIN выполнился за 14 мс, а LEFT — вдвое медленнее. Логика проста: INNER JOIN позволяет оптимизатору лучше использовать индексы.

Вот ключевые отличия в работе:

• INNER JOIN: только совпадения, меньше данных для обработки.
• LEFT JOIN: все строки слева + NULL для несовпадений, больше нагрузки на память.
• Нюанс: оптимизатор иногда перестраивает LEFT JOIN в INNER, если результат идентичен.

Сравнение скорости на примерах

Представьте таблицу заказов (orders) и клиентов (customers). INNER JOIN покажет только заказы с клиентами. LEFT JOIN — все заказы, даже без клиента. Если клиентов мало, LEFT JOIN обработает много NULL и замедлится.

В реальном тесте на SQL Server INNER JOIN с вставкой данных обошёл LEFT JOIN, несмотря на лишние операции. Запрос с INNER выполнился в 2 раза быстрее на малых данных, а на больших — разрыв ещё больше. Почему? INNER JOIN минимизирует сканирование таблиц.

Другой пример: linked server. INNER JOIN тянет данные эффективно, LEFT JOIN отправляет лишние запросы на удалённый сервер. Тест показал, что LEFT JOIN генерирует параллельные запросы медленнее в Elastic Query.

Сравним в таблице типичные сценарии:

• Масштаб данных: на 100k строк INNER в 2 раза быстрее.
• Важно: всегда проверяйте execution plan в SQL Server или Explain в PostgreSQL.

Когда LEFT JOIN может быть быстрее

Не всегда INNER JOIN лидирует. Если в левой таблице почти все строки имеют совпадения, LEFT JOIN может оптимизироваться в INNER. Оптимизатор видит это и переписывает план.

В Oracle или MySQL LEFT JOIN иногда выигрывает при плохих индексах на правой таблице. Но это редкость. Тесты показывают: для удаления несовпадающих строк комбо INNER + DELETE быстрее чистого LEFT.

Пример: таблица пользователей и профилей. Вместо LEFT JOIN переместить данные и использовать INNER — скорость растёт. Контр-интуитивно, но работает на больших объёмах.

Факторы влияния:

• Индексы: на join-колонках INNER использует их лучше.
• Статистика: устаревшая статистика путает LEFT JOIN.
• Серверы: локально разница мала, удалённо — INNER доминирует.
• Нюанс: в WHERE после LEFT JOIN он превращается в INNER.

Оптимизация запросов с JOIN

Начинайте с INNER JOIN, если нужны только совпадения. Переходите на LEFT только по логике. Проверяйте план выполнения: ищите сканирования вместо seek.

Используйте фильтры в ON, а не WHERE для LEFT JOIN — сохранит NULL. Добавляйте индексы на join-поля. Тестируйте на реальных данных, не на toy-примерах.

Таблица оптимизаций:

• EXISTS vs JOIN: для проверки наличия EXISTS быстрее LEFT на больших данных.
• Порядок таблиц: ставьте большую слева в LEFT JOIN.
• Совет: профилируйте с SET STATISTICS IO ON.

Мифы и реальные бенчмарки

Миф: LEFT JOIN всегда медленнее. Нет, если логика требует все строки. Но для совпадений — всегда INNER. Тесты Бен Надела: INNER в 2 раза быстрее даже с лишними шагами.

В SQLShack INNER чище читается и быстрее. RIGHT JOIN редко нужен — замените на LEFT. Oracle форумы: INNER удаляет нематчи эффективнее.

Факты из тестов:

• Малые таблицы: паритет.
• Большие: INNER до 2x быстрее.
• Linked: INNER минимизирует трафик.

Практические советы по выбору

Всегда выбирайте JOIN по логике, а не по мифам о скорости. INNER JOIN для связанных данных, LEFT — для полного списка слева. Тестируйте execution plan и IO-статистику.

Осталось за кадром: влияние FULL OUTER JOIN или CROSS. Стоит поэкспериментировать с вашими данными — планы уникальны для каждой БД.