Всем привет. Помните викторину ?

Сколько строк вернет следующий sql запрос ? Таблицы смотри на изображении.

SELECT * FROM orders o JOIN payments p ON o.user_id = p.user_id;

Не простая она оказалась=). Сейчас разберем.
Правильный ответ на самом деле - 5 строк. Почему 5 ?


Как работает JOIN (упрощенно конечно же).
В запросе соединяются таблицы orders и payments по столбцу ON o.user_id = p.user_id.
Условно, каждая строка столбца user_id таблицы orders должна проверить все строки столбца user_id таблицы payments.
Берется первая строка столбца user_id таблицы orders, в которой записано значение 10.
Грубо говоря это число 10 проверяет первую строку столбца user_id таблицы payments, и там тоже 10, в итоге 10 = 10 строки соединяются. Получаем:
10 10
Дальше первая строка столбца user_id все той же таблицы orders, в которой записано значение 10, проверяет вторую строку столбца user_id таблицы payments, но и там тоже 10, получается снова 10 = 10. В итоге уже:
10 10
10 10
Следующим этапом ВТОРАЯ строка столбца user_id таблицы orders, в которой тоже записано значение 10 проверяет все строки таблицы payments. В итоге:
10 10
10 10
10 10
10 10

Строка с числом 20 таблицы orders не нашла себе совпадений в payments, строка не попадает в результат, а вот число 30 одной таблицы нашло себе одно совпадение в другой, 30 = 30. Финал:

10 10
10 10
10 10
10 10
30 30

Ответ: 5 строк.

Если объяснил криво, задавайте вопросы).

Когда сделал DELETE FROM table и забыл про WHERE…

Внезапно узнаёшь три важные истины:

1. Что такое autocommit.
2. Что писать BEGIN вручную было не такой уж плохой идеей.
3. Что таблица может быть чистой… а совесть — нет.

«Если ты застрял на 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 и аналитику данных, оконные функции — обязательный пункт.