SQL

БЛОК 3. JOIN — 11. JOIN — базовые соединения

📚 22 вопросовПройти тест →
Лекция

БЛОК 3. JOIN — 11. JOIN — базовые соединения

SQL

11. JOIN — базовые соединения

🧭 Введение: как связать данные из разных таблиц

В реальных проектах данные почти никогда не лежат в одной таблице.
Пользователи отдельно, заказы отдельно, платежи отдельно, роли отдельно.
Чтобы собрать полезный ответ для API или отчёта, нужно уметь сопоставлять строки между таблицами.
Именно это делает JOIN.
Главная точка риска: из-за одного условия в WHERE можно случайно сломать логику соединения и получить не те данные.
💡 Совет: Перед написанием JOIN всегда отвечайте на вопрос: «какие строки из левой таблицы обязаны остаться в результате?».
✅ Вывод: JOIN — это не просто синтаксис, а контроль бизнес-логики сопоставления данных.

⚠️ Проблема -> решение

Типичный старт новичка:
  1. соединяет таблицы без явного понимания «кто главный»,
  2. путает INNER JOIN и LEFT JOIN,
  3. добавляет фильтр в WHERE и случайно превращает LEFT JOIN в INNER JOIN.
Результат:
  1. пропадают нужные строки,
  2. в отчётах и API появляются «дыры»,
  3. дебаг занимает много времени.
Решение:
  1. сначала зафиксировать логику сохранения строк (все/только совпавшие),
  2. выбрать тип соединения осознанно,
  3. аккуратно ставить условия либо в ON, либо в WHERE по задаче.
🟢 Если совсем просто: INNER JOIN оставляет только совпадения, LEFT JOIN сохраняет все строки слева.
🎯 Как понять, что этап прошёл успешно: Вы можете заранее предсказать, какие строки исчезнут, а какие останутся после JOIN.

🛠️ Чем помогает и как работает

JOIN нужен в каждом backend-проекте: карточка пользователя с заказами, список курсов с прогрессом, отчёт по оплатам.
Без соединений пришлось бы делать много отдельных запросов и склеивать данные вручную.
🟢 Если совсем просто: JOIN связывает таблицы по ключам и возвращает единый набор данных.
🎯 Как понять, что этап прошёл успешно: Вы уверенно строите запрос «основная сущность + связанные данные».
Чем помогает:
  • объединяет нормализованные таблицы в рабочую выборку;
  • сокращает количество лишней логики в приложении;
  • делает отчёты и API-поля консистентными;
  • позволяет явно управлять поведением при отсутствии связи.
Как это работает:
  • Шаг 1: выбираем «левую» таблицу (база результата).
  • Шаг 2: задаём условие сопоставления в ON.
  • Шаг 3: выбираем тип JOIN (INNER, LEFT).
  • Шаг 4: добавляем фильтрацию (WHERE) и проверяем, не ломает ли она логику.
  • Шаг 5: проверяем NULL-строки после LEFT JOIN.
✅ Вывод: Сильный JOIN-запрос начинается с понимания бизнес-смысла, а не с выбора случайного шаблона.

📚 Ключевые термины (простыми словами)

Перед практикой синхронизируем словарь.
🟢 Если совсем просто: Эти термины объясняют, как именно SQL «склеивает» строки.
🎯 Как понять, что этап прошёл успешно: Вы без подсказок объясняете разницу INNER JOIN и LEFT JOIN.
  • JOIN (соединение) — объединение строк из нескольких таблиц по условию.
  • Join condition (условие соединения) — правило сопоставления строк в ON.
  • INNER JOIN — оставляет только строки, где совпадение найдено в обеих таблицах.
  • LEFT JOIN — сохраняет все строки левой таблицы, даже если справа совпадения нет.
  • Matched row (совпавшая строка) — строка, у которой найдена пара по условию ON.
  • Unmatched row (несовпавшая строка) — строка без пары; в LEFT JOIN справа получит NULL.
  • ON — место, где задаётся условие соединения.
  • NULL after LEFT JOIN — признак отсутствия связанной записи справа.
✅ Вывод: Если понимать эти 8 терминов, большая часть ошибок в JOIN уходит на этапе проектирования запроса.

🔗 1. Логика сопоставления строк

Перед любым JOIN важно понять, какие ключи связывают таблицы.
Обычно это PK -> FK: например, users.id = orders.user_id.
🟢 Если совсем просто: JOIN ищет пару строк по правилу из ON.
🎯 Как понять, что этап прошёл успешно: Вы точно знаете, какое поле с каким сравнивается и почему.
Назначение: Сопоставить записи двух таблиц в единую рабочую выборку.
Простыми словами: Если ключи совпали, строки «склеились»; если нет, поведение зависит от типа JOIN.
Для новичка: Начинайте с явных алиасов (u, o) и полного условия в ON.
Аналогия: Это как находить пару «человек -> пропуск» по номеру документа.
Пример:
SELECT  u.id,  u.email,  o.id AS order_id,  o.total_amountFROM users uINNER JOIN orders o  ON o.user_id = u.id;
🔎 Как это происходит на практике:
  • Контекст: backend отдаёт список заказов вместе с данными пользователя.
  • Действия: связывает users и orders по user_id.
  • Результат: каждая строка содержит поля из обеих таблиц.
Характеристики:
  • качество соединения зависит от правильности ключей;
  • неоднозначное условие ON быстро приводит к дубликатам;
  • явные алиасы делают запросы проще для ревью.
Когда использовать: Всегда, когда бизнес-данные распределены по нескольким таблицам.
✅ Вывод: Правильный ключ сопоставления — фундамент любого корректного JOIN.

🤝 2. INNER JOIN: только совпавшие строки

INNER JOIN возвращает только те строки, где условие ON выполнилось с обеих сторон.
Если пара не найдена, строка в итог не попадает.
🟢 Если совсем просто: INNER JOIN = пересечение двух таблиц по правилу сопоставления.
🎯 Как понять, что этап прошёл успешно: Вы осознанно используете INNER JOIN, когда отсутствие связи должно исключать строку.
Назначение: Получать только полностью связанные данные.
Простыми словами: Нет заказа у пользователя — не будет строки в результате.
Для новичка: INNER JOIN безопасен, когда в бизнес-логике нужны только «полные пары».
Аналогия: Список студентов с зачётом: попадают только те, у кого есть и студент, и оценка.
Пример:
SELECT  o.id AS order_id,  u.email,  o.total_amountFROM orders oINNER JOIN users u  ON u.id = o.user_idWHERE o.status = 'paid';
🔎 Как это происходит на практике:
  • Контекст: отчёт по оплаченной выручке.
  • Действия: выбираются только заказы с валидным пользователем.
  • Результат: нет «висячих» строк без связи.
Характеристики:
  • возвращает только совпадения;
  • хорошо подходит для строгих связей;
  • при плохих данных может скрыть проблему отсутствующей связи.
Когда использовать: Когда строка без связи бизнесу не нужна.
✅ Вывод: INNER JOIN полезен для «чистых» выборок, но может отрезать важные строки без совпадения.

🧩 3. LEFT JOIN: сохраняем левую таблицу и получаем NULL справа

LEFT JOIN всегда сохраняет строки левой таблицы.
Если справа совпадения нет, колонки правой таблицы будут NULL.
🟢 Если совсем просто: LEFT JOIN = «всё слева обязательно, справа по возможности».
🎯 Как понять, что этап прошёл успешно: Вы понимаете, почему после LEFT JOIN появляются NULL и что они означают.
Назначение: Сохранить полный список базовой сущности даже при отсутствии связи.
Простыми словами: Пользователь без заказа всё равно остаётся в результате, но поля заказа будут пустыми.
Для новичка: NULL после LEFT JOIN обычно означает «связанной записи нет», а не «ошибка SQL».
Аналогия: Список всех сотрудников и их машин: у кого машины нет, колонка машины пустая.
Пример:
SELECT  u.id,  u.email,  o.id AS order_id,  o.status AS order_statusFROM users uLEFT JOIN orders o  ON o.user_id = u.id;
🔎 Как это происходит на практике:
  • Контекст: CRM показывает всех клиентов, включая тех, кто ещё ничего не купил.
  • Действия: базой берётся users, заказы присоединяются через LEFT JOIN.
  • Результат: «новые» пользователи видны, даже если заказов нет.
Характеристики:
  • все строки слева сохраняются;
  • справа NULL для несопоставленных строк;
  • удобно для поиска «кто ещё не сделал действие».
Когда использовать: Когда важно сохранить полный набор левой сущности.
✅ Вывод: LEFT JOIN нужен, когда отсутствие связи тоже является полезной информацией.

🎯 4. Фильтрация после JOIN: ON и WHERE

После соединения легко ошибиться местом фильтра.
Условия в ON и WHERE могут давать разный результат, особенно с LEFT JOIN.
🟢 Если совсем просто: ON управляет сопоставлением, WHERE фильтрует итоговые строки.
🎯 Как понять, что этап прошёл успешно: Вы осознанно решаете, фильтр должен влиять на матчинг или на итоговую выборку.
Назначение: Контролировать, какие пары строк образуются и какие строки попадут в финал.
Простыми словами: Одинаковое условие в разных местах может либо сохранить «пустые» строки, либо удалить их.
Для новичка: Для LEFT JOIN условия по правой таблице часто лучше ставить в ON, если хотите сохранить левую таблицу полностью.
Аналогия: ON — правила знакомства, WHERE — кого пустили в финальный список гостей.
Пример (фильтр в ON):
SELECT  u.id,  u.email,  o.id AS paid_order_idFROM users uLEFT JOIN orders o  ON o.user_id = u.id AND o.status = 'paid';
Пример (фильтр в WHERE):
SELECT  u.id,  u.email,  o.id AS paid_order_idFROM users uLEFT JOIN orders o  ON o.user_id = u.idWHERE o.status = 'paid';
Вариант бизнес-правила «paid ИЛИ без заказов»:
SELECT  u.id,  u.email,  o.id AS order_id,  o.statusFROM users uLEFT JOIN orders o  ON o.user_id = u.idWHERE o.status = 'paid'   OR o.id IS NULL;
Здесь логика в WHERE осознанная: нужны только пользователи с paid-заказом или без заказов вообще.
🔎 Как это происходит на практике:
  • Контекст: нужно показать всех пользователей и их оплаченный заказ, если он есть.
  • Действия: условие o.status = 'paid' ставится в ON.
  • Результат: пользователи без paid-заказа остаются в списке.
Характеристики:
  • ON влияет на сам факт совпадения строк;
  • WHERE применяется после соединения;
  • для LEFT JOIN фильтр по правой таблице в WHERE часто меняет смысл результата.
Когда использовать: Когда важно точно контролировать, сохраняются ли строки левой таблицы.
✅ Вывод: В JOIN место фильтра — это часть бизнес-логики, а не вопрос стиля.

🚨 5. Классическая ошибка: LEFT JOIN превращается в INNER JOIN

Это самая частая ловушка в реальных проектах.
Пишут LEFT JOIN, но добавляют в WHERE условие по правой таблице и теряют строки с NULL.
🟢 Если совсем просто: WHERE right_table.column = ... после LEFT JOIN часто «съедает» левую таблицу без совпадений.
🎯 Как понять, что этап прошёл успешно: Вы сразу замечаете риск конвертации LEFT в фактический INNER.
Назначение: Избежать тихих ошибок в отчётах и API-выборках.
Простыми словами: Если справа NULL, условие в WHERE обычно не проходит, и строка удаляется.
Для новичка: Если надо сохранить строки слева, переносите условия по правой таблице в ON или явно учитывайте NULL.
Аналогия: Вы пригласили всех сотрудников, но на входе пропускаете только тех, у кого есть авто — остальные исчезают из списка.
Антипример:
SELECT  u.id,  u.email,  o.id AS order_idFROM users uLEFT JOIN orders o  ON o.user_id = u.idWHERE o.status = 'paid';
Корректный вариант:
SELECT  u.id,  u.email,  o.id AS order_idFROM users uLEFT JOIN orders o  ON o.user_id = u.id AND o.status = 'paid';
🔎 Как это происходит на практике:
  • Контекст: админка должна показать всех пользователей и статус их оплаты.
  • Действия: условие по оплате ошибочно ставят в WHERE.
  • Результат: «неплатившие» пропадают, и команда принимает неверные решения.
Характеристики:
  • ошибка часто проходит незаметно, без SQL-исключения;
  • особенно критична для отчётов «кто не сделал действие»;
  • исправляется переносом фильтра в ON или явной логикой IS NULL.
Когда использовать: Всегда проверять этот риск при ревью LEFT JOIN.
✅ Вывод: Проверка на «LEFT -> INNER» должна быть обязательным пунктом каждого SQL-ревью.

🧬 6. JOIN размножает строки: нормальное поведение, частая ловушка

Ещё одна частая причина «странных цифр» после LEFT -> INNER: соединение само по себе может увеличить число строк.
Если у пользователя 3 заказа, то в результате users LEFT JOIN orders этот пользователь появится 3 раза.
🟢 Если совсем просто: JOIN возвращает по строке на каждое совпадение, а не «одну строку на пользователя».
🎯 Как понять, что этап прошёл успешно: Перед COUNT(*) или SUM(...) после JOIN вы проверяете кардинальность связи (1:1, 1:N, N:N).
Назначение: Предотвращать дубли и неверные метрики в отчётах.
Простыми словами: JOIN «разворачивает» левую строку столько раз, сколько совпадений нашлось справа.
Для новичка: Сначала решите, какой результат нужен: одна строка на сущность или список связанных строк.
Аналогия: Один клиент и три чека = три строки в выгрузке, это ожидаемо.
Пример:
SELECT  u.id,  o.id AS order_idFROM users uLEFT JOIN orders o  ON o.user_id = u.id;
🔎 Как это происходит на практике:
  • Контекст: аналитик считает пользователей после JOIN и получает число больше ожидаемого.
  • Действия: проверяет связь users -> orders и видит кардинальность 1:N.
  • Результат: метрика исправляется через агрегацию/подзапрос/EXISTS в зависимости от задачи.
Характеристики:
  • умножение строк при 1:N и N:N — нормальное поведение;
  • COUNT(*) после JOIN часто считает не сущности, а пары сопоставления;
  • для «одна строка на пользователя» нужны дополнительные техники (агрегация, подзапрос, DISTINCT ON, оконные функции).
Когда использовать: Всегда учитывать этот эффект перед расчётом агрегатов по результату JOIN.
✅ Вывод: JOIN не «портит» данные, но меняет гранулярность результата — это нужно контролировать.

🔍 7. EXISTS как альтернатива JOIN для проверки наличия (semi join)

Иногда JOIN вообще не нужен.
Если цель — проверить, есть ли связанные записи, чаще лучше использовать EXISTS.
🟢 Если совсем просто: EXISTS отвечает на вопрос «существует ли хотя бы одна связанная строка».
🎯 Как понять, что этап прошёл успешно: Для задачи «выбрать пользователей, у которых есть ...» вы сначала рассматриваете EXISTS, а не JOIN.
Назначение: Избежать лишних дублей и упростить запрос на проверку существования связи.
Простыми словами: Нам не нужен список заказов, нам нужен факт, что заказ есть.
Для новичка: Если не выбираете поля правой таблицы, EXISTS часто точнее и безопаснее.
Аналогия: Вы проверяете, есть ли у человека хотя бы один пропуск, а не распечатываете все пропуска.
Пример:
SELECT  u.id,  u.emailFROM users uWHERE EXISTS (  SELECT 1  FROM orders o  WHERE o.user_id = u.id    AND o.status = 'paid');
🔎 Как это происходит на практике:
  • Контекст: backend строит фильтр «пользователи с оплаченным заказом».
  • Действия: использует EXISTS вместо JOIN.
  • Результат: запрос не размножает строки и проще читается.
Характеристики:
  • не возвращает колонки правой таблицы;
  • не создаёт дубли из-за 1:N связей;
  • хорошо подходит для «есть/нет» условий.
Когда использовать: Когда нужна проверка наличия связи, а не подробный список связанных строк.
✅ Вывод: EXISTS — базовый production-паттерн для задач «у кого есть связанная запись».

🆚 Сравнение: INNER JOIN vs LEFT JOIN

КонструкцияЧто сохраняетЧто происходит без совпаденияТипичное применение
INNER JOINТолько совпавшие строкиСтрока исчезаетСтрогие связи, где нужны только полные пары
LEFT JOINВсе строки левой таблицыСправа NULLПолный список сущностей + опциональные связи
✅ Вывод: Выбор между INNER и LEFT должен исходить из бизнес-вопроса «кого нельзя потерять».

🧠 Must-Know (запомнить)

  • JOIN всегда начинается с правильного условия сопоставления в ON.
  • INNER JOIN отрезает строки без пары, LEFT JOIN их сохраняет.
  • NULL после LEFT JOIN обычно означает отсутствие связанной записи.
  • Для LEFT JOIN фильтр по правой таблице в WHERE часто ломает логику.
  • Ошибку «LEFT превратился в INNER» нужно проверять отдельно.
  • JOIN может размножать строки при 1:N и N:N связях — это влияет на агрегаты.
  • Для условий «существует связанная запись» часто лучше EXISTS, чем JOIN.
  • Алиасы таблиц (u, o) повышают читаемость и уменьшают риск ошибок.
✅ Вывод: Эти 8 правил покрывают большинство практических задач и ревью-замечаний по JOIN.

❌ Частые мифы

❌ Миф: LEFT JOIN всегда безопасен и ничего не может испортить. ✅ Как правильно: LEFT JOIN легко сломать фильтром в WHERE по правой таблице. 📎 Почему это важно: можно тихо потерять строки и получить неверный отчёт.
❌ Миф: если есть JOIN, то тип соединения не так важен. ✅ Как правильно: тип JOIN напрямую определяет, какие строки останутся в результате. 📎 Почему это важно: один неверный тип соединения меняет бизнес-смысл выборки.
❌ Миф: NULL после LEFT JOIN означает ошибку данных. ✅ Как правильно: чаще это нормальный признак отсутствия связанной строки. 📎 Почему это важно: NULL после LEFT JOIN часто нужен для аналитики «кто ещё не сделал действие».
❌ Миф: все фильтры лучше ставить в WHERE. ✅ Как правильно: в JOIN часть фильтров должна быть в ON, чтобы сохранить правильную логику сопоставления. 📎 Почему это важно: неправильное место фильтра меняет результат даже при корректном синтаксисе.

🎤 Часто спрашивают на собеседованиях

❓ Вопрос: В чём разница между INNER JOIN и LEFT JOIN? ✅ Ответ: INNER JOIN оставляет только совпавшие строки, LEFT JOIN сохраняет все строки слева и подставляет NULL справа при отсутствии совпадения.
❓ Вопрос: Что означает NULL в колонках правой таблицы после LEFT JOIN? ✅ Ответ: это признак того, что связанной записи в правой таблице не найдено по условию ON.
❓ Вопрос: Почему WHERE o.status = 'paid' после LEFT JOIN может быть ошибкой? ✅ Ответ: потому что строки без совпадения справа имеют NULL, не проходят условие в WHERE и удаляются из результата.
❓ Вопрос: Когда условие по правой таблице ставить в ON, а не в WHERE? ✅ Ответ: когда нужно сохранить все строки левой таблицы и лишь ограничить, какие строки справа можно присоединить.
❓ Вопрос: Как проверить, что LEFT JOIN не превратился в INNER JOIN? ✅ Ответ: посмотреть, остаются ли строки левой таблицы без совпадений справа и нет ли фильтров по правой таблице в WHERE.

🚨 Типичные ошибки

  • Соединять по неключевым полям (email, title) вместо PK/FK: текстовые поля меняются, бывают неуникальными и чувствительны к регистру.
  • Выбирать LEFT JOIN «на всякий случай», не понимая, кого нужно сохранить.
  • Ставить фильтр по правой таблице в WHERE после LEFT JOIN.
  • Путать NULL-результат связи с «плохими данными».
  • Использовать SELECT * в сложных JOIN и терять контроль над колонками.
  • Не давать алиасы таблицам и получать неоднозначные запросы.
✅ Вывод: Большинство проблем в JOIN связаны не с синтаксисом, а с неверной логикой сопоставления.

✅ Best Practices

  • Всегда начинайте с вопроса: «какая таблица базовая и какие строки нельзя потерять».
  • Соединяйте таблицы по PK/FK, а не по «похожим» текстовым полям.
  • В JOIN явно указывайте алиасы и каждую колонку в SELECT.
  • Для LEFT JOIN осторожно используйте WHERE по правой таблице.
  • Проверяйте поведение на кейсах «есть связь / нет связи».
  • На ревью отдельно проверяйте риск «LEFT -> INNER».
  • Пишите SQL-примеры с комментариями к ключевым строкам.
✅ Вывод: Системный подход к JOIN делает выборки предсказуемыми и надёжными для продакшена.

🏁 Заключение

Базовые соединения INNER JOIN и LEFT JOIN — фундамент любого SQL-бэкенда.
Они определяют, какие данные увидит приложение и какие решения примет команда по отчётам.
Если вы уверенно контролируете сопоставление строк, NULL после LEFT JOIN и место фильтра (ON vs WHERE), вы уже пишете зрелый SQL.
✅ Вывод: Главное в JOIN — не тип сам по себе, а точная логика сохранения и отбора строк.
🎯

Проверьте знания

Закрепите материал — пройдите тест по теме «БЛОК 3. JOIN — 11. JOIN — базовые соединения»

Пройти тест →