Серия «SQL: знакомство»

CASE WHEN - часто используемое условное выражение в запросах. Его особенности и факты далее.

А пока подписывайся на мой канал На связи: SQL Там я публикую посты про особенности и нюансы SQL. Этот канал про то, как не бояться баз данных, понимать, что такое JOIN, GROUP BY и почему NULL ≠ 0. Его я веду с нуля подписчиков. Присоединяйся!

CASE - возвращает значение, но не управляет логикой выполнения запроса.

SELECT

name,

CASE

WHEN salary > 100000 THEN 'богач'

WHEN salary BETWEEN 50000 AND 100000 THEN 'норм'

ELSE 'бедняк'

END AS category

FROM employees;

Здесь CASE не «делает выборку», а вычисляет новое значение для каждой строки.

Где используется CASE

✅ В SELECT - чтобы выводить вычисленные поля
✅ В WHERE - чтобы сделать фильтрацию условной
✅ В ORDER BY - чтобы сортировать по кастомной логике
✅ В GROUP BY и HAVING - для агрегатов с условиями

Пример в ORDER BY:

ORDER BY

CASE WHEN status = 'vip' THEN 1 ELSE 2 END

В итоге VIP-клиенты окажутся первыми — без лишнего UNION или сортировки по тексту.

Где нельзя использовать CASE

• Нельзя динамически подменять им названия колонок или таблиц — SQL так не работает:

SELECT * FROM CASE WHEN ... THEN table1 ELSE table2 END -- ошибка

• Нельзя изменять структуру запроса — CASE не может выбирать, какие поля попадут в SELECT.

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

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

1. CASE возвращает первое совпадение

SQL идёт сверху вниз — как только условие совпало, остальные даже не проверяются.
Поэтому важно порядок условий.

CASE

WHEN score > 80 THEN 'A'

WHEN score > 90 THEN 'A+' -- никогда не сработает

END

Потому что >80 ловит всё, включая >90.

2. Тип результата — общий для всех веток

CASE пытается привести все результаты к единому типу.
Если ты вернёшь 'текст' и NULL, всё ок.
Но если 'текст' и 123, то SQL может выдать ошибку или привести число к строке.
💡 Всегда делай значения одного типа, особенно если потом используешь CASE в арифметике.

3. Есть две формы: сравнительная и поисковая

Обычно используют поисковую:

CASE WHEN condition THEN result ... END

Но есть ещё сравнительная:

CASE status

WHEN 'new' THEN 1

WHEN 'active' THEN 2

END

Она короче, но менее гибкая — работает только с равенством (=).

4. CASE + агрегаты = мощный аналитический трюк

Чтобы посчитать агрегаты по категориям в одной строке:

SELECT

SUM(CASE WHEN gender = 'M' THEN 1 ELSE 0 END) AS male_count,

SUM(CASE WHEN gender = 'F' THEN 1 ELSE 0 END) AS female_count

FROM users;

Один запрос, два счётчика, без подзапросов и джойнов.

5. CASE в WHERE — не всегда оптимален

Когда ты используешь CASE в WHERE, PostgreSQL часто не может применить индекс,
потому что условие становится непредсказуемым.

Пример:

WHERE

CASE WHEN is_vip THEN discount > 10 ELSE discount > 30 END

Лучше выносить логику в OR:

WHERE (is_vip AND discount > 10)

OR (NOT is_vip AND discount > 30)

Так планировщик сможет использовать индексы (их наличие подразумевается)

Где CASE особенно полезен

• Когда нужно сделать динамическую сегментацию данных (категории, статусы, группы)

• При построении витрин и отчётов (разделить аудиторию, выделить группы риска и т.п.)

• Для чистки данных на лету (заменить NULL на текст или дефолтное значение)

• В AB-тестах — присвоить группе метку на основании условия

Если тебе нравятся такие разборы SQL с реальными примерами и подводными камнями —
подписывайся на мой Telegram На связи: SQL

Простые функции. Кажется, что они находят просто минимум и максимум. Но есть и особенность их использования для интерпретации результатов. Об этом далее.

А пока подписывайся на мой канал На связи: SQL Там я публикую посты про особенности и нюансы SQL. Этот канал про то, как не бояться баз данных, понимать, что такое JOIN, GROUP BY и почему NULL ≠ 0. Его я веду с нуля подписчиков. Присоединяйся!

MIN и MAX — не только про числа

Они работают с любыми типами данных:

• датами (MIN(date) даст самую раннюю дату),

• строками (MAX(name) вернёт последнюю в алфавитном порядке),

• булевыми значениями (MIN(bool) — false, MAX(bool) — true).

Иногда этим можно ловко воспользоваться — например, чтобы узнать, есть ли хоть один true:

SELECT MAX(is_active) FROM users;

Если вернёт true — значит, кто-то активен. Красиво и лаконично.

MIN и MAX — не только агрегатные, но и оконные функции

Можно получить минимум или максимум в рамках окна, не теряя детализацию:

SELECT

user_id,

date,

MAX(date) OVER (PARTITION BY user_id) AS last_activity

FROM logins;

Так можно легко вытащить, когда пользователь последний раз заходил — без группировки и без JOIN.

MIN/MAX и NULL

Они игнорируют NULL.
То есть если у тебя все значения NULL, то результат — NULL.
Это часто ломает аналитику, особенно при сравнении с COALESCE или при объединении данных.

SELECT MAX(COALESCE(score, 0)) -- вернёт 0, а не NULL

→ Иногда важно явно заменить NULL, чтобы не получить "пустой" результат.

MIN/MAX могут ускорить выборку

Если в таблице есть индекс по нужному полю —
MIN() и MAX() используют только крайний элемент индекса.
Это значит, что:

SELECT MAX(price) FROM products;

может пройтись не по миллиону строк, а просто взять последнее значение из B-tree индекса.
То есть — мгновенно.

Можно найти строку с минимальным/максимальным значением

Классическая боль аналитика: как вытащить не просто максимум, а всю строку, где он встретился.

💡 Один из лучших способов — оконная функция + фильтр:

SELECT *

FROM (

SELECT *,

ROW_NUMBER() OVER (ORDER BY salary DESC) AS rn

FROM employees

) t

WHERE rn = 1;

→ Получаем сотрудника с максимальной зарплатой.
Без подзапросов, без JOIN, без боли.

Неочевидный кейс: поиск экстремумов в группах

SELECT department, MIN(salary), MAX(salary)

FROM employees

GROUP BY department;

Классика, но важно:
разница между MAX и MIN = разброс значений, полезный показатель в аналитике (например, зарплат).

💬 Если хочешь больше таких разборов с реальными кейсами SQL без воды — подписывайся на мой Telegram 👉На связи: SQL
Там я рассказываю про SQL так, чтобы стало интересно даже тем, кто раньше его ненавидел 😄

Когда мы видим AVG, кажется, всё просто:

Возьми все значения и найди среднее арифметическое.

Но на практике AVG часто ведёт себя не так, как ты ожидаешь — и это причина десятков аналитических факапов в отчётах.

А пока подписывайся на мой каналНа связи: SQL Там я публикую посты про особенности и нюансы SQL. Этот канал про то, как не бояться баз данных, понимать, что такое JOIN, GROUP BY и почему NULL ≠ 0. Его я веду с нуля подписчиков. Присоединяйся!

Что делает AVG()?

AVG() - агрегатная функция. Она считает среднее значение по всем строкам, которые попали в выборку после фильтрации WHERE

SELECT AVG(column_name)

FROM table_name

WHERE condition;

Пример:

| id | salary |
| -- | ------ |
| 1 | 1000 |
| 2 | 2000 |
| 3 | NULL |
| 4 | 3000 |

SELECT AVG(salary) FROM employees;

Результат → 2000

❗ Почему не (1000 + 2000 + 0 + 3000) / 4 = 1500?

Потому что AVG игнорирует NULL.
Он считает (1000 + 2000 + 3000) / 3.

Если тебе нужно учесть “отсутствие зарплаты” как ноль —
надо явно это сказать базе:

SELECT AVG(COALESCE(salary, 0)) FROM employees;

Где используется AVG

AVG() — базовый инструмент в аналитике:

• 📈 средний чек (AVG(order_amount))

• 💰 средняя зарплата по отделу

• 🕒 среднее время выполнения заказа

• ⭐ средний рейтинг продукта

Но это только верхушка айсберга.
Ниже — интересные кейсы, где AVG используется неочевидно, но мощно 👇

Обычный AVG считает всё одинаково,
но в реальном мире “вес” данных может быть разный.

Пример — средняя оценка курса:

| user_id | rating | reviews |
| ------- | ------ | ------- |
| 1 | 5 | 1 |
| 2 | 4 | 20 |

Если ты просто возьмёшь AVG(rating) → 4.5
Но по факту второй пользователь оставил 20 отзывов, его мнение должно весить больше:

SELECT SUM(rating * reviews) / SUM(reviews) AS weighted_avg

FROM ratings;

Вот это уже взвешенное среднее, и результат будет ближе к 4.

AVG не коммутативен в агрегациях

AVG(AVG(...)) ≠ AVG(...)

Пример:

| group | value |

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

| A | 10 |

| A | 20 |

| B | 100 |

| B | 100 |

| B | 100 |

SELECT AVG(avg_val) FROM (

SELECT group, AVG(value) AS avg_val

FROM t GROUP BY group

) s;

Результат будет → 57.5
А реальное среднее по всей таблице = 86.

Почему?
Потому что при втором AVG каждая группа имеет одинаковый “вес”,
а не количество строк. Это типичный аналитический капкан.

AVG в окнах (window functions)

AVG() можно использовать по “скользящему окну”, чтобы считать динамику:

SELECT

date,

AVG(price) OVER (ORDER BY date ROWS 6 PRECEDING) AS moving_avg_7d

FROM stock_prices;

👉 Это 7-дневное скользящее среднее — классика анализа временных рядов, трейдинга и предсказания трендов.

Среднее как критерий “нормальности”

В аналитике AVG часто используют вместе со STDDEV:

STDDEV (Standard Deviation) — стандартное отклонение (среднеквадратичное отклонение). Это статистическая мера разброса данных относительно их среднего значения в определённом периоде.

SELECT *

FROM purchases

WHERE amount > AVG(amount) + 3 * STDDEV(amount);

Так находят аномально большие значения — подозрительные платежи, мошеннические операции и т.д.

AVG по датам — это тоже работает

Мало кто знает, что AVG() можно применять даже к датам:

SELECT AVG(order_date)::date FROM orders;

PostgreSQL переведёт даты во внутренние числа и вычислит “среднюю дату” —
по сути, середину временного диапазона.
Это удобно, если хочешь понять, когда чаще всего происходили события.

AVG и производительность

AVG() всегда вычисляется через SUM и COUNT,
поэтому если ты делаешь:

SELECT COUNT(*), SUM(amount), AVG(amount)

— оптимизатор посчитает всё за один проход по данным.
Но если AVG в отдельном запросе — будет второй проход.
Мелочь, а при миллионах строк чувствуется.

Мой канал На связи: SQL ждет тебя, если ты тоже хочешь познакомиться с базовым языком для аналитики данных.

Подписывайся!

Когда мы слышим «COUNT» и «SUM» мы подразумеваем - «считает строки», «суммирует числа»

Но даже для таких действий есть тонкости и нюансы.

А пока подписывайся на мой канал На связи: SQL Там я публикую посты про особенности и нюансы SQL. Этот канал про то, как не бояться баз данных, понимать, что такое JOIN, GROUP BY и почему NULL ≠ 0. Его я веду с нуля подписчиков. Присоединяйся!

В большинстве случаев мы используем 3 вида COUNT

• COUNT(*) — считает все строки, даже пустые.

• COUNT(column) — считает только те строки, где есть данные.

• COUNT(DISTINCT column) — считает уникальные значения в column.
  

Рассмотрим на конкретном примере:

| id | name | gift |
-------------------------------
| 1 | Оля | Торт |
| 2 | Вася | NULL |
| 3 | Маша | Цветы |
| 4 | Петя | Торт |
| 5 | Катя | NULL |
| 6 | Оля | Торт |

COUNT(*)

Считаем все строки, независимо от содержимого колонок:

SELECT COUNT(*) FROM guests;

Результат: 6

• Всего 6 гостей пришло.

• Неважно, принес ли кто-то подарок или нет, учитывается каждая строка.

COUNT(gift)

Считаем только те строки, где колонка gift не NULL:

SELECT COUNT(gift) FROM guests;

Результат: 4

• Только Оля (Торт), Маша (Цветы), Петя (Торт), Оля (Торт) учитываются.

• Вася и Катя, у которых gift = NULL, не считаются.

• Эта разница показывает: сколько записей реально имеют данные по этой колонке.

COUNT(DISTINCT gift)

Считаем уникальные подарки:

SELECT COUNT(DISTINCT gift) FROM guests;

Результат: 2

• Есть только два уникальных подарка: Торт и Цветы.

• Независимо от того, сколько гостей принесли одинаковый подарок, каждый подарок считается один раз.

🔍 Что это говорит при анализе данных

• COUNT(*) — общее количество записей (все строки).

• COUNT(column) — сколько строк с заполненным значением в колонке.

• COUNT(DISTINCT column) — сколько уникальных значений встречается в колонке.

Вывод: разница между этими числами может показать пропуски (NULL) и повторяющиеся данные. Это важно при анализе — если просто взять COUNT(*), можно недооценить проблему с пропущенными значениями.

Ну а теперь рассмотрим SUM

Чтобы показать, как эта функция работает и какие тонкости бывают, рассмотрим таблицу:
Таблица orders:
| id | customer | amount |
| -- | -------- | ------ |
| 1 | Оля | 100 |
| 2 | Вася | NULL |
| 3 | Маша | 200 |
| 4 | Петя | 150 |
| 5 | Катя | NULL |
| 6 | Оля | 100 |

1️⃣ SUM(amount)
Считаем сумму по колонке amount (игнорирует NULL):

SELECT SUM(amount) FROM orders;

Результат: 550

• Складываются только числа: 100 + 200 + 150 + 100 = 550

• NULL не учитываются

• Если бы все значения были NULL, результат был бы NULL, а не 0

2️⃣ SUM(DISTINCT amount)

Считаем сумму уникальных значений:

SELECT SUM(DISTINCT amount) FROM orders;

Результат: 450

• Уникальные значения amount: 100, 150, 200

• Складываем их: 100 + 150 + 200 = 450

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

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

🔍 Важные моменты

1. NULL не участвуют — всегда нужно помнить, что SUM(column) не считает NULL.

2. DISTINCT меняет результат — если в колонке повторяются значения, сумма с DISTINCT будет меньше обычной суммы.

3. Суммирование строк с пропусками — может дать неожиданное ощущение «потери данных».

Вывод:

• SUM(column) = фактическая сумма всех чисел

• SUM(DISTINCT column) = сумма только уникальных чисел

• Важно учитывать NULL, иначе можно получить неожиданные результаты

Все знают GROUP BY.
Тот самый оператор, который превращает кучу строк в аккуратную табличку с суммами и средними.

Но можно и по-другому взглянуть на GROUP BY

А пока подписывайся на мой канал На связи: SQL Там я публикую посты про особенности и нюансы SQL. Этот канал про то, как не бояться баз данных, понимать, что такое JOIN, GROUP BY и почему NULL ≠ 0. Его я веду с нуля подписчиков. Присоединяйся!

В большинстве случаев GROUP BY используют вместе с агрегирующими функциями SUM, COUNT или AVG.

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

1. В качестве изящной замены DISTINCT

   SELECT department FROM employees GROUP BY department;

   работает так же, как

   SELECT DISTINCT department FROM employees;

2. Группировать можно по выражениям, а не только по столбцам

   Например, хочешь посчитать заказы по годам:

   SELECT EXTRACT(YEAR FROM created_at) AS year, COUNT(*)

   FROM orders

   GROUP BY EXTRACT(YEAR FROM created_at);

   Или сгруппировать товары по тысячам рублей:

   SELECT (price / 1000)::int AS price_group, COUNT(*)

   FROM products

   GROUP BY (price / 1000)::int;

3. GROUP BY умеет строить иерархии

   ROLLUP, CUBE, GROUPING SETS — три команды богов:

   SELECT region, city, SUM(sales)

   FROM orders

   GROUP BY ROLLUP (region, city);

   → покажет суммы по городам, по регионам и общий итог.
   И всё это одним запросом.

4. NULL — это тоже группа

   Если у тебя несколько строк с NULL в поле department,
   то GROUP BY department соберёт их все в одну группу NULL.

   SELECT department, COUNT(*)

   FROM employees

   GROUP BY department;

   Логичней использовать COALESCE, чтобы потом не работать с пустыми строками

   SELECT COALESCE(department, 'Unknown') AS department, COUNT(*)

   FROM employees

   GROUP BY COALESCE(department, 'Unknown');

5. SELECT vs GROUP BY — всё, что не агрегат, должно быть в GROUP BY

   SELECT department, name, COUNT(*)

   FROM employees

   GROUP BY department;

   Запрос упадёт, потому что name не в агрегате и не в GROUP BY.

   В PostgreSQL есть хитрости: можно использовать array_agg(name) или string_agg(name, ', ')

6. GROUP BY и оконные функции — не конкуренты

   GROUP BY сжимает таблицу.
   OVER(PARTITION BY) — сохраняет строки, но добавляет агрегат.

   SELECT name, department,

   SUM(salary) OVER (PARTITION BY department) AS dep_total

   FROM employees;

7. SQL сам решает, как группировать

   PostgreSQL может выбрать:

   • HashAggregate — если данных много

   • Sort + GroupAggregate — если их мало или мало уникальных значений

   То есть одна и та же команда GROUP BY под капотом работает по-разному.
   Вот почему один и тот же запрос на 10k строк работает мгновенно, а на 10M — вечность.
   
   PostgreSQL не просто тупо группирует строки, а выбирает стратегию (план выполнения) — как именно эту группировку реализовать.
   

   Это можно отследить в EXPLAIN и уже потом контролировать включением/выключением конкретных алгоритмов.

   SET enable_hashagg = off;

   SET enable_sort = off;

   Это полезно для тестирования или отладки - посмотреть, как изменится план.

GROUP BY — это не просто «посчитать среднюю зарплату по отделу».
Это мощный инструмент, который может:

• имитировать DISTINCT

• строить иерархические отчёты

• объединяться с оконными функциями

• …и при этом легко устроить тебе день боли, если ты не знаешь, что делаешь 😅

Псевдонимы в SQL (алиасы) кажутся «косметикой», но у них есть подводные камни и тонкости, которые реально влияют на запросы.

Псевдонимы - это временные имена для таблиц или столбцов внутри запроса.

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

SELECT c.name AS customer_name

FROM customers c;

• c — алиас таблицы customers

• customer_name — алиас для колонки c.name

Внутри результата ты видишь только customer_name.

Где применяются

Сокращение длинных имён

SELECT o.id, c.name

FROM orders o

JOIN customers c ON o.customer_id = c.id;

- читабельнее, чем всё время писать orders.id, customers.name

JOIN и self-join
Без алиасов нельзя отличить таблицы при самосоединении:

SELECT e1.name, e2.name
FROM employees e1
JOIN employees e2 ON e1.manager_id = e2.id;

Агрегация и подзапросы
Алиас часто обязателен:

SELECT avg(salary) AS avg_salary

FROM employees;

Derived tables (подзапросы в FROM)
Тут алиас обязателен:

SELECT sub.department, sub.cnt

FROM ( SELECT department, count(*) cnt

FROM employees

GROUP BY department

) sub;

Где их нельзя применять / ограничения

В том же уровне WHERE

SELECT salary * 1.2 AS new_salary

FROM employees

WHERE new_salary > 5000; -- ❌ Ошибка

• Алиасы доступны только в SELECT/ORDER BY, но не в WHERE или GROUP BY.
  → нужно повторно писать выражение или завернуть в CTE.

  Порядок обработки
  SQL выполняется в порядке: FROM → JOIN → WHERE → GROUP BY → HAVING → SELECT → ORDER BY → LIMIT.
  Алиасы появляются только после SELECT.
  Поэтому:

  • в WHERE и GROUP BY алиасы ещё не видны;

  • в ORDER BY алиасы уже можно использоват

Нюансы, которые часто забывают

1. Алиасы влияют только на внешний уровень запроса
   Они не меняют структуру таблицы.
   В EXPLAIN ты увидишь исходные имена столбцов, а не алиасы.

2. В подзапросах алиас обязателен для таблицы
   Даже если кажется, что можно без него.

SELECT *

FROM (SELECT 1) -- ❌ Ошибка

SELECT *

FROM (SELECT 1) AS t;

1. ORDER BY может использовать алиас
   Ускоряет жизнь:

   SELECT salary * 1.2 AS new_salary
   FROM employees
   ORDER BY new_salary DESC;

2. CTE против алиасов
   Если выражение слишком длинное (например, CASE WHEN …), лучше вынести его в CTE вместо алиаса в SELECT → так его можно переиспользовать и в WHERE, и в ORDER BY.

3. Алиасы могут влиять на читаемость, но и запутывать
   Пример анти-паттерна:

   SELECT u.id AS order_id -- ❌ псевдоним вводит в заблуждение
   FROM users u;

   → плохая идея, потому что вводит читателя в ошибку.

Итог: алиасы — не просто косметика. Это инструмент:

• для читаемости;

• для самосоединений и подзапросов;

• для управления порядком сортировки.

Но они не живут дольше SELECT-а

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

Про 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 и давай изучать особенности вместе!