«Если ты застрял на JOIN, подзапросе или еще на чем нибудь — с тобой всё в порядке»


Учить SQL — это не история про «с первого урока всё понятно», а про тот самый момент, когда на 10‑й попытке вдруг щёлкает, и запрос наконец начинает работать так, как ты хотел.​
JOIN, подзапросы, GROUP BY, NULL, оконные функции — поначалу выглядят как магия, и это нормально: под капотом там много логики, о которой редко говорят в базовых туториалах.​

Даже опытные разработчики иногда сидят по полчаса над одним SELECT: меняют порядок JOIN, переставляют условия, смотрят план выполнения и думают: «Почему оно так считает, а не так?».​
Раздражение, желание всё удалить и написать заново, ощущение «я ничего не понимаю» — это не знак, что у тебя не получается, это просто честный этап обучения любому нетривиальному инструменту.​

Важно не скорость, с которой ты начал писать «идеальные» sql запросы, а количество раз, когда ты вернулся к задаче и попробовал ещё раз, вместо того чтобы окончательно забить.​
Каждый такой маленький «камбэк» формирует насмотренность: ты начинаешь видеть типовые паттерны данных, чувствовать, какой sql запрос получится проще, а какой лучше разбить на шаги.

5 основных причин медленных SQL запросов.

1. Отсутствие селективных условий и лишние данные.

Запросы без достаточных фильтров (широкие WHERE, отсутствие LIMIT) читают гораздо больше строк, чем реально нужно.

Использование SELECT * вместо явного списка колонок увеличивает объём передаваемых и обрабатываемых данных.​

2. Неудачные JOIN’ы и подзапросы.

Сложные JOIN‑конструкции с лишними таблицами, неточными условиями или неиспользуемыми полями приводят к огромным промежуточным результатам.

Коррелированные подзапросы в SELECT/WHERE вместо JOIN часто реализуются как вложенные циклы по строкам и легко дают квадратичное время.​

3. Неправильное использование операторов сравнения.

LIKE с ведущим % (например, '%abc') и сложные выражения в WHERE мешают использованию индексов и ведут к полным сканам.

Функции и вычисления над колонками в условиях (например, lower(col) = 'x') тоже могут отключать индексы, если не используются функциональные индексы.​

4. «Тяжёлые» агрегации и сортировки.

GROUP BY/ORDER BY по большим наборам без разумных фильтров или предварительной агрегации создают большие сортировки в памяти/на диске.

DISTINCT «на всякий случай» вместо осмысленного дизайна запроса заставляет движок сортировать или хешировать большие множества строк.​

5. Плохая работа с большими выборками.

Отсутствие пагинации и попытка за один запрос вытащить десятки/сотни тысяч строк приводит к долгому ответу и тяжёлой нагрузке на сеть и приложение.

🔍 Что такое планировщик запросов и как он работает в PostgreSQL.

Когда вы отправляете в базу простой запрос вроде:

SELECT * FROM users WHERE age > 30 ORDER BY age;

кажется, что PostgreSQL просто «читает таблицу и возвращает данные».
Но на самом деле перед выполнением запроса включается мощный мозг — планировщик запросов.

И именно он решает, как выполнить запрос быстрее всего.

🧠 Что такое планировщик запросов?

Планировщик запросов — это компонент СУБД, который анализирует SQL-запрос и выбирает оптимальный план его выполнения.

Это как навигатор: вы указываете точку назначения, а он выбирает маршрут — короткий, быстрый или сбалансированный.

В PostgreSQL планировщик — часть системы optimizer (оптимизатора), и это один из самых серьёзных элементов движка.

⚙️ Как работает планировщик?

Когда вы отправляете запрос, PostgreSQL проходит несколько стадий:

1️⃣ Парсинг (разбор запроса)

Проверка синтаксиса, построение дерева запроса.

2️⃣ Анализ статистики

Планировщик смотрит в специальные системные таблицы и оценивает:

- сколько строк в таблице;
- как распределены значения в столбцах;
- есть ли индексы и насколько они селективны;
- есть ли ограничения, уникальные ключи, внешние ключи;
- и др.

Это позволяет понять: выборка будет маленькой или огромной?

3️⃣ Генерация возможных планов

PostgreSQL может выполнить запрос десятками способов:

- полное сканирование таблицы (Seq Scan);
- использование индекса (Index Scan);
- частичное чтение индекса (Index Only Scan);
- Bitmap Index Scan;
- разные виды JOIN: Nested Loop, Hash Join, Merge Join;
- выполнение фильтра до или после соединения;
- сортировки, группировки и т. д.

4️⃣ Оценка стоимости каждого плана

Каждому варианту присваивается стоимость из учета затрачиваемых на выполнения запроса ресурсов (cost):
чем меньше cost — тем быстрее выполнение.

Учитывается:

- объём чтения с диска,
- размер данных,
- сложность сортировки,
- необходимость хеширования,
- количество повторных проходов.

5️⃣ Выбор оптимального плана

Планировщик выбирает план с наименьшей стоимостью — и передаёт его исполнительному модулю (executor).

🔎 Пример: почему запрос иногда «не использует индекс»

Многие удивляются:

«Я создал индекс, но PostgreSQL игнорирует его!»

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

Например, если таблица маленькая или условие слишком широкое, индекс не уменьшит объём работы, а вероятно даже увеличит.

Планировщик часто прав — он работает на основании статистики.

Знаете ли вы, что в PostgreSQL можно создавать свои собственные программки прямо внутри СУБД?

В PostgreSQL есть много встроенных функций, задача которых облегчать нам жизнь.

Например:

- round(3.14159, 2) возвращает 3.14
- length('PostgreSQL') возвращает 10
- now() возвращает текущую дату и время

Почти любая операция уже готова к использованию.

А что, если вам нужно каждый день считать некоторый финансовый показатель магазина, например — цена × количество × (1 - скидка) × (1 + НДС) с округлением, то писать это заново утомительно, а готового решения вероятно не будет.

Создайте свою программу, то есть функцию прямо на SQL:

CREATE OR REPLACE FUNCTION calc_revenue(price NUMERIC, qty INTEGER, discount NUMERIC DEFAULT 0)
RETURNS NUMERIC AS
$$
SELECT round(price * qty * (1 - discount) * 1.20, 2);
$$ LANGUAGE SQL;

Теперь просто вызываете функцию, указывая там свои параметры:

SELECT calc_revenue(1000, 5, 0.1); — 5400.00

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

📊 Данные как зеркало бизнеса: что они говорят о компании ?

У каждого бизнеса есть своё зеркало.
Нет, не то, в котором отражается офис или логотип.
А то, в котором отражается его настоящее состояние — сильные стороны, слабые места, ошибки, победы и возможности.
И этим зеркалом являются данные.

🔍 1. Данные показывают не то, что бизнес хочет видеть, а то, что есть на самом деле.

Можно бесконечно обсуждать стратегию, спорить о гипотезах и строить красивые презентации.
Но когда мы открываем данные — всё становится проще и честнее.

В цифрах нет эмоций.
Нет оправданий.
Нет «нам казалось».

Есть только факты.
И это делает данные самым честным источником истины в компании.

🧭 2. Данные показывают направление развития.

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

Данные — это навигатор.
Без него можно долго ехать красиво, но в неверную сторону.

🫥 3. Данные подсвечивают проблемы, которые иначе останутся в тени.

Часто компания узнаёт о проблеме только тогда, когда она становится слишком большой.

Но данные умеют предупреждать заранее:

- падает активность пользователей;
- уменьшается конверсия;
- растут издержки;
- клиенты уходят чуть быстрее, чем приходят.

Если смотреть в зеркало регулярно — можно заметить трещины, пока они ещё маленькие.

📈 4. Данные показывают зрелость компании

У зрелых компаний есть культура измерений.
Они знают свои ключевые метрики, отслеживают изменения, строят прогнозы и принимают решения осознанно.

У незрелых — хаос.
Данные либо отсутствуют, либо не доверяют тем, что есть, либо смотрят на них только тогда, когда «припекло».

Зрелость бизнеса начинается там, где начинается зрелость работы с данными.

💬 5. Что главное?

Данные — это не просто отчёты.
Это не цифры ради цифр.
Это голос бизнеса.

Если прислушаться, данные говорят:

- где вы сильны,
- где ошибаетесь,
- куда стоит идти,
- а куда — точно не стоит.

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

🏁 Итог

Данные — это отражение бизнеса.
Аналитика — способ увидеть это отражение ясно.
И те, кто умеют с этим работать, дают компании шанс расти осознанно, а не вслепую.

Всем привет.
Разберем прошлый вопрос про псевдонимы.
Правильным ответом был: В GROUP BY и ORDER BY.
Это вот такая особенность PostgreSQL.
В некоторых других СУБД псевдоним не работает даже в GROUP BY.
Что кажется логичным с точки зрения логического порядка работы операторов внутри системы.
В HAVING и WHERE псевдоним точно не работает, т.к. сам SELECT работает позже чем эти два.

🧠 SQL-запрос, который должен знать каждый аналитик: накопительный итог в PostgreSQL.

Если ты работаешь с аналитикой данных, рано или поздно понадобится накопительный итог:
выручка по дням, количество пользователей, прогресс метрик и т.д.

❌ Многие начинают с подзапросов и GROUP BY
✅ Но в PostgreSQL это решается одной оконной функцией

Разберём на примере.

Допустим, есть таблица orders:

order_date    | amount
--------------+--------
2024-01-01    | 100
2024-01-02    | 200
2024-01-03    | 150

Нужно посчитать накопительную сумму продаж по дням.

🔥 Правильный SQL-запрос:

SELECT
      order_date,
      amount,
      SUM(amount) OVER (ORDER BY order_date) AS running
FROM orders
ORDER BY order_date;

📌 Что здесь происходит

- SUM(amount) — считаем сумму
- OVER() — превращает агрегат в оконную функцию
- ORDER BY order_date — задаёт порядок накопления

👉 PostgreSQL сам «идёт» по строкам и суммирует значения.

Результат будет таким:

order_date  | amount| running
------------+-------+--------
2024-01-01  |   100 |  100               
2024-01-02  |   200 |  300   
2024-01-03  |   150 |  450   

💡 Почему это важно:

- без подзапросов
- читаемый SQL
- часто спрашивают на собеседованиях по SQL

Если ты изучаешь SQL, PostgreSQL и аналитику данных, оконные функции — обязательный пункт.

🕒 7 полезных функций для работы с датами и временем в PostgreSQL.

Если ты работаешь с SQL, то рано или поздно упрёшься в даты.
Фильтры, группировки, периоды, интервалы — всё это про них.

Разберём 7 функций PostgreSQL, которые реально нужны в работе.

1️⃣ NOW() — текущее дата и время:

SELECT NOW(); — 2025-12-16 14:23:10.456

Используется, когда нужно «текущее состояние» — сейчас, в этот момент.

2️⃣ CURRENT_DATE — текущая дата (без времени):

SELECT CURRENT_DATE; — 2025-12-16

Удобно для фильтрации по дням.

3️⃣ DATE_TRUNC() — усечение даты:

SELECT DATE_TRUNC('month', '2025-12-16'); — 2025-12-01 00:00:00

Очень часто используется для:

- группировки по месяцам
- неделям
- дням

4️⃣ AGE() — разница между датами:

SELECT AGE('2025-12-16', '2025-11-10'); — 1 mon 6 days

Возвращает разницу в удобном формате, а не просто число дней.

5️⃣ EXTRACT() — получить часть даты:

SELECT EXTRACT(YEAR FROM '2025-12-16');— 2025

Можно извлекать: YEAR, MONTH, DAY, HOUR, WEEK и т.д.

6️⃣ INTERVAL — работа с периодами времени

SELECT '2025-12-16'::date + INTERVAL '7 days'; — 2025-12-23

Незаменимо для:

- расчёта дедлайнов
- временных окон
- анализа периодов

7️⃣ TO_CHAR() — форматирование даты:

SELECT TO_CHAR('2025-12-16', 'YYYY-MM'); — 2025-12

Используется, когда нужно красиво вывести дату в отчётах.

🐘 Чем на самом деле занимаются администраторы баз данных (DBA).

Про DBA часто думают так:

«Ну… это человек, который следит, чтобы база не упала».

И да — это правда.
Но это лишь процентов 10 от того, чем DBA занимается на самом деле.

Разберёмся 👇

🔧 1. DBA отвечают за надёжность данных

Для бизнеса данные — это деньги, клиенты и история.
DBA делают всё, чтобы:

- данные не пропали
- данные не повредились
- данные можно было восстановить

Бэкапы, репликации, тесты восстановления — их ежедневная рутина.

⚡️ 2. DBA борются за производительность

Если запросы вдруг стали «тормозить»,
скорее всего, DBA уже это заметил.

Они:

- анализируют планы выполнения
- ищут узкие места
- настраивают индексы
- оптимизируют конфигурацию БД

И делают так, чтобы система выдерживала рост нагрузки.

🔐 3. DBA отвечают за безопасность

Кто имеет доступ к данным?
Кто может читать, кто — изменять, а кто — только смотреть?

DBA настраивают:

- роли и права
- доступы
- защиту от случайных и неслучайных ошибок

Чтобы данные не «утекали» и не ломались.

🚑 4. DBA — первые, кого будят ночью

Если база «легла» в 3 часа ночи —
DBA узнаёт об этом первым.

Он:

- ищет причину
- поднимает систему
- минимизирует потери
- делает выводы, чтобы это не повторилось

Спокойствие продакшена — их заслуга.

🧠 5. DBA — это про системное мышление

Хороший DBA понимает не только базу данных, но и:

- как работает приложение
- как идут запросы
- как растёт нагрузка
- где может возникнуть проблема

Они думают на несколько шагов вперёд.

🏁 Итог

DBA — это не просто «админ базы».
Это инженер, который делает так, чтобы бизнес мог спокойно работать, масштабироваться и не бояться за свои данные.

Если база работает стабильно и быстро —
скорее всего, где-то рядом есть хороший DBA.

UNION, EXCEPT, INTERSECT — операции объединения множеств в SQL.

В SQL есть мощный инструмент, про который знают не все,
но который сильно упрощает запросы — операции над множествами.

Если коротко:
они позволяют объединять и сравнивать результаты запросов.

Разберёмся 👇
------------------------------------------------------------------
🔹 UNION — объединить результаты

UNION объединяет результаты двух запросов и убирает дубликаты.

SELECT user_id FROM users_2024
UNION
SELECT user_id FROM users_2025;

Получим всех уникальных пользователей за два года.

Если дубликаты нужны — используйте UNION ALL.

------------------------------------------------------------------
🔹 INTERSECT — найти общее

INTERSECT возвращает только те строки,
которые есть в обоих результатах.

SELECT user_id FROM paid_users
INTERSECT
SELECT user_id FROM active_users;

Пользователи, которые и платят, и активны.


------------------------------------------------------------------
🔹 EXCEPT — найти разницу

EXCEPT показывает строки,
которые есть в первом запросе, но отсутствуют во втором.

SELECT user_id FROM users
EXCEPT
SELECT user_id FROM banned_users;

Все пользователи, кроме заблокированных.

------------------------------------------------------------------
⚠️ Важно помнить

Чтобы операции работали корректно, необходимо:

- одинаковое количество колонок
- одинаковые типы данных
- одинаковый порядок колонок

И да — порядок запросов в EXCEPT имеет значение.

Когда это реально полезно:

- сравнение сегментов
- анализ изменений
- поиск пересечений аудиторий
- очистка данных
- сложная аналитика без лишних JOIN’ов

История о том, как LEFT JOIN превратился в INNER JOIN, но никто этого не заметил.

Был у меня запрос. Красивый, аккуратный, должен был выводить все заказы, даже те, которые НЕ в статусе 'paid'.

SELECT *
FROM orders o
LEFT JOIN payments p ON p.order_id = o.id
WHERE p.status = 'paid';

Смотрю — LEFT JOIN.
Думаю: ну всё правильно, хотим же заказы, даже если оплаты нет.

Запрос работает. Данные возвращает. Прод живёт.

Проходит время.

Приходит вопрос:
— А почему у нас пропали заказы без оплаты? У нас что все заказы только оплаченные?

Я открываю запрос, смотрю ещё раз.
LEFT JOIN — есть.
Вроде всё логично.

А потом PostgreSQL тихо так подсказывает:
— Друг, ты уверен, что это LEFT JOIN?

Я отвечаю:
— Уверен, написано же LEFT JOIN !!

Он продолжает:
— У тебя в запросе условие WHERE p.status = 'paid' —
это не фильтр таблицы orders.
Это фильтр результата после JOIN.

— И для строк, где оплаты нет,
p.status равен NULL.

— А NULL = 'paid' — это не TRUE.
Это ничего. Поэтому я просто выкидываю эти строки.

В этот момент LEFT JOIN:
— Я вообще-то был левым…

А WHERE отвечает:
— Был. Теперь ты INNER.

Исправление оказалось простым, условие нужно было перенести в LEFT JOIN:

SELECT *
FROM orders o
LEFT JOIN payments p ON p.order_id = o.id AND p.status = 'paid';

Вывод:
LEFT JOIN — не гарантия того, что строки сохранятся.
Одно условие в WHERE — и вы сами превращаете его в INNER JOIN.

PostgreSQL не ошибается.
Он просто выполняет то, что вы написали.
Даже если вы написали это «логично».

🎄 Друзья, вот и подходит к концу 2025 год.

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

А всё нужное и ценное — опыт, знания, идеи и желание развиваться —
смело забираем с собой в 2026 год.

Уверен, впереди нас ждёт год интересный, технологичный и полный новых открытий.
Пусть будет больше удачных решений, роста, уверенности в себе
и, конечно, достижения всех поставленных целей.

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

С наступающим Новым 2026 годом! 🚀
Пусть он будет сильным, продуктивным и по-настоящему вашим.