Про JOIN обычно пишут общую теоретическую информацию. Всегда упоминают виды JOIN-ов: INNER, LEFT, RIGHT, FULL, CROSS, а за кулисами могут остаться интересные факты, подводные камни и тонкости, которые редко упоминаются, но которые могут реально пригодиться.

В моем канале На связи: SQL уже есть про это посты: вот этот и вот этот. Канал я веду с нуля подписчиков. Чтобы показать, что аналитика и SQL это не страшно, а интересно. Присоединяйся, если ты тоже хочешь начать изучать SQL или вспомнить и осознать некоторые нюансы.

Неочевидные факты про JOIN

Условие в ON vs WHERE

• Для INNER JOIN — разницы нет, фильтрация в ON или в WHERE даст одинаковый результат.

• Но для LEFT JOIN это уже не так:

  • ON фильтрует при объединении (строка может остаться с NULL в правой таблице).

  • WHERE фильтрует после — и может "выбросить" строки, ради которых делался LEFT JOIN.

👉 Классический баг у новичков: пишут условие в WHERE и не понимают, почему LEFT превратился в INNER.

Предположим, у нас есть две таблицы:

orders (таблица заказов):

order_id | customer_id | amount

---------|-------------|--------

1 | 1 | 100

2 | 2 | 200

3 | 1 | 150

customers (таблица клиентов):

customer_id | country

------------|---------

1 | USA

2 | UK

3 | USA

И есть два запроса:

SELECT o.order_id, c.customer_id, c.country

FROM orders o

LEFT JOIN customers c ON o.customer_id = c.customer_id

AND c.country = 'USA';

SELECT o.order_id, c.customer_id, c.country

FROM orders o

LEFT JOIN customers c ON o.customer_id = c.customer_id

WHERE c.country = 'USA';

Результаты этих запросов будут одинаковы?

Можно писать свои рассуждения в комментариях.

JOIN на неравенстве

Обычно мы пишем ON a.id = b.id, но можно и:

SELECT *

FROM a

JOIN b ON a.value BETWEEN b.min AND b.max;

Это называется non-equi join (неравенственный джойн).
👉 В BI и аналитике это часто используют для «поиска диапазона» (например, попадает ли дата заказа в акцию).
Но! Такой JOIN почти всегда тяжелее, потому что индексы плохо помогают.

FULL JOIN в проде почти не используют

Многие базы его поддерживают, но реально на проектах встречается редко. Почему?

• Почти всегда можно заменить комбинацией LEFT JOIN UNION RIGHT JOIN.

• А оптимизаторы некоторых СУБД работают с FULL OUTER JOIN медленнее.
  👉 Часто факт наличия FULL JOIN в запросе сигнализирует, что "что-то не так со схемой данных".

CROSS JOIN — не только для Декарта

Все думают, что CROSS JOIN = "перемножить всё на всё". Но он используется:

• для генерации тестовых данных:

SELECT d::date

FROM generate_series('2025-01-01', '2025-01-31', interval '1 day') d

CROSS JOIN users;

для построения матриц, календарей, отчетов с дырками.
👉 То есть CROSS JOIN часто — инструмент BI-разработчика

JOIN и NULL — подстава

• NULL = NULL → всегда FALSE.
  Поэтому если соединяешь таблицы по колонке с NULL, то такие строки просто теряются.
  👉 В проде это часто ломает аналитику: ожидали, что будет связь «пустое с пустым», а SQL этого не понимает.

Производительность JOIN-ов

• Много JOIN-ов (10+) ≠ всегда медленно. Оптимизаторы умеют работать с огромными планами.

• Но JOIN + функции (ON lower(a.name) = lower(b.name)) почти всегда убивает индекс → дорого.
  👉 Лучшее решение — хранить данные в нормализованном виде (например, имена в нижнем регистре).

ANTI JOIN

Вместо NOT IN или NOT EXISTS можно писать LEFT JOIN ... WHERE b.id IS NULL.
Это часто быстрее, особенно в старых версиях MySQL.
👉 Но не забывай: NOT IN (NULL, ...) ведет себя неожиданно (возвращает пустой набор).

JOIN ≠ JOIN ORDER

SQL — декларативный язык. Ты пишешь JOIN-ы в любом порядке, но оптимизатор сам решает, какую таблицу читать первой, как переставить местами соединения. Поэтому писать «самую маленькую таблицу первой» часто не имеет смысла. Но иногда хинты (JOIN ORDER, FORCE JOIN, USE INDEX) всё же нужны, когда оптимизатор ошибается.

Когда мы пишем:

SELECT *

FROM orders o

JOIN customers c ON o.customer_id = c.id

JOIN regions r ON c.region_id = r.id;

мы как бы говорим:
👉 «Дай мне все заказы, вместе с клиентами и регионами».

НО! Мы не указываем порядок, в котором эти таблицы реально будут соединяться.
Оптимизатор (query planner) сам решает:

• какую таблицу читать первой;

• по какому индексу идти;

• в каком порядке выполнять JOIN-ы.

И этот порядок почти всегда ≠ порядок в SQL-запросе.

Как это работает на практике

• Оптимизатор строит граф зависимостей между таблицами и условиями.

• Считает «стоимость» разных стратегий (в PostgreSQL это cost-based optimizer).

• Выбирает план с минимальной стоимостью: например, начать с маленькой таблицы, потом по индексу сходить в большую.

OIN ORDER hints

Иногда оптимизатор ошибается. Причины:

• Неправильная статистика (например, таблица только что обновилась).

• Очень сложный запрос (10+ JOIN-ов, подзапросы).

• Особенности движка (MySQL раньше любил «сначала левую таблицу»).

Тогда СУБД позволяют подсказать оптимизатору:

• FORCE ORDER (SQL Server, Oracle) → использовать JOIN-ы в том порядке, как написаны.

• LEADING (Oracle) → указать, с какой таблицы начать.

• USE INDEX (MySQL) → подсказать, какой индекс использовать.

• PostgreSQL не имеет FORCE JOIN, но можно:

  • отключить конкретные алгоритмы (SET enable_hashjoin = off;)

  • использовать LATERAL, JOIN LATERAL, CROSS JOIN чтобы «подсказать» порядок.

🔹 Когда порядок JOIN реально важен

1. Суперсложные запросы (20+ таблиц).
   Оптимизатор может выбрать очень дорогой план → запрос работает минуты/часы.
   Иногда правильный хинт → ускорение в десятки раз.

2. Необновлённая статистика.
   Оптимизатор думает: «таблица маленькая», но на самом деле она разрослась. → выбирает плохой порядок JOIN.

3. LIMIT + ORDER BY.
   Тут реально важно, с чего начать — иногда оптимизатор «тянет» всю таблицу, хотя мог бы остановиться раньше.

🔹 Лайфхак для практики

• В PostgreSQL можно посмотреть план:

  EXPLAIN (ANALYZE, BUFFERS) SELECT ...

  → увидишь реальный JOIN order.

• Не доверяй слепо «писать маленькую таблицу первой» — это миф, из старых времён MySQL.

• Иногда лучше переписать запрос так, чтобы оптимизатору нечего было гадать. Например, вынести фильтрацию в CTE или subquery.

JOIN — это не только "соединить таблицы", а целый набор особенностей: от NULL и порядка фильтрации до генерации календарей через CROSS JOIN.

Подписывайся на мой канал На связи SQL и давай изучать особенности вместе!

Сегодня профессия аналитик данных на слуху у многих. И это неудивительно: мы живем в мире, где ежедневно производим огромные объемы информации. Чуть меньше из этого мы храним в структурированном виде. И совсем малую часть — действительно используем.

Вот здесь и появляются аналитики данных. Они — те самые, кто умеет собирать, обрабатывать, хранить и интерпретировать данные так, чтобы на их основе можно было принимать решения.

Но очень многих пугает это завуалированное понятие "аналитик данных".

Когда люди сталкиваются с понятием SQL, то самое первое, что им выдает любой поиск - это определение что такое SQL.

SQL (Structured Query Language) — язык структурированных запросов. Предназначен для работы с реляционными базами данных (БД) — массивами информации, которые связаны между собой и представлены в виде таблиц.

И сразу кажется, что SQL — это что-то очень сложное и скучное. Мол, только серьезные люди решают серьезные кейсы, строят модели, прогнозируют будущее бизнеса и ведут суровые Excel-файлы.

Но даже знакомство с SQL можно сделать проще и даже немного веселее.

Почему SQL — это как мамин ответ "где мои носки"

Да, многие скажут, что "не веселится" идут в аналитику, а решать реальные, серьезные кейсы, помогать бизнесу строить свои процессы, получать прибыль и т.д.
Да, это все так, но этап знакомство с SQL может быть и "веселее". Если хотя бы информацию для начинающих и тех, кто просто знакомится с SQL преподносить более "приземленным" способом.

Да, серьезные вещи надо обсуждать серьезным языком. Но ведь нас в школе не сразу заставляют читать Войну и мир Толстого, а дают Букварь с картинками. А картинки там, чтобы была ассоциация с тем, что уже знакомо, и чтобы веселее было изучать.

Так и с SQL. Это действительно серьезный язык запросов (не программирования), но на нём говорят и мамы, и папы, и дизайнеры, и строители — просто не знают, что это называется SQL.

Пример №1: мама как база данных

Мама каждый день слышит:

• где мои синие носки для спорта

• где лежат подгузники

• где штаны от костюма

• а что такое планета?

Она знает, где что лежит. Мама — это не просто база знаний, она ещё и движок запросов:

SELECT *

FROM Flat

WHERE things = 'подгузники';

Квартира — это база данных, тумбочки/шкафы — таблицы, мама — мастер SQL-запросов.

Пример №2: дизайнер и объединение таблиц

Дизайнер интерьера создает гармоничное пространство, объединяя, казалось бы, разные стили, цвета, формы. Но у них есть что-то общее, что делает интерьер целостным.

SQL делает то же самое:

SELECT *

FROM Furniture

JOIN Textiles

ON Furniture.color = Textiles.color;

Мы объединяем данные из разных таблиц, чтобы получить единую картину — понятную и полезную.

Кому будет интересна эта серия постов?

Я готовлю серию постов о SQL — простыми словами, с жизненными аналогиями, с нуля. Это будет интересно:

• студентам и новичкам в аналитике

• тем, кто хочет сменить сферу и понять, "что там у этих дата-людей"

• тем, кто хочет просто научиться разговаривать с данными на их языке

Если вы уже знакомы с SQL — приходите в комментарии! Расскажите, что помогло вам освоить этот язык? Что может "завлечь" новичков?

А ещё у меня появился канал про SQL

Пока там только один подписчик — я сама :) Но планов много:
📊 практичные посты
📚 объяснение синтаксиса без занудства
🧩 разбор типичных задач аналитиков

👉 Присоединяйтесь: На связи: SQL

И, конечно, мой мотивационный канал продолжает радовать короткими сообщениями, которые настраивают на день:
✨ Сила слов

SQL — это не страшно. Это просто способ спросить: "Где лежат подгузники?"