Как работают джойны SQL?

На приведенной ниже схеме подробно показано, как работают 4 типа объединений SQL.

🔹INNER JOIN возвращает совпадающие строки в обеих таблицах
🔹LEFT JOIN возвращает все записи из левой таблицы и соответствующие записи из правой
🔹RIGHT JOIN возвращает все записи из правой таблицы и соответствующие записи из левой
🔹FULL OUTER JOIN возвращает все записи, в которых есть совпадения, в левой или правой таблице

📲 Мы в MAX

#db

👉 @database_info

Сегодня расскажу вам про одну часто недооценённую, но крайне полезную SQL-фишку — CROSS APPLY в SQL Server (и его аналог в других СУБД — LATERAL).

Когда обычный JOIN бессилен

Допустим, у нас есть таблица Orders, и мы хотим для каждой строки выбрать топ-1 продукт по сумме, но выборка зависит от строки — тут уже обычный JOIN не справится. Вот пример, где приходит на помощь CROSS APPLY:

SELECT 
    o.OrderID,
    p.ProductName,
    p.Amount
FROM Orders o
CROSS APPLY (
    SELECT TOP 1 *
    FROM Products p
    WHERE p.OrderID = o.OrderID
    ORDER BY p.Amount DESC
) p;

Что делает CROSS APPLY?

Он буквально говорит: «Для каждой строки из Orders выполни подзапрос с её параметрами». Это похоже на foreach, где внутренняя выборка может меняться в зависимости от строки внешней таблицы.

Аналог в PostgreSQL:

SELECT 
    o.order_id,
    p.product_name,
    p.amount
FROM orders o,
LATERAL (
    SELECT *
    FROM products p
    WHERE p.order_id = o.order_id
    ORDER BY p.amount DESC
    LIMIT 1
) p;

🔥 Используйте CROSS APPLY, когда:
- Нужна подстрочная логика внутри запроса
- Не получается реализовать через обычный JOIN
- Вы работаете с функциями, которые возвращают таблицу (TVF)

📲 Мы в MAX

#db

👉 @database_info

SQL. Как работать с датами в SQL Server

Из строки в дату и обратно
Приведение строки к дате

-- формат dd.mm.yyyy
select try_convert(date, isnull(@fielddateBirth,'01.01.1980'), 104)

-- формат yyyy-mm-dd
select try_convert(date, isnull(@fielddateBirth,'1980-01-01'), 23)

Приведение даты к строке

-- формат dd.MM.yyyy
select try_convert(nvarchar(16), getdate(), 104)

-- формат yyyy-mm-dd
select convert(nvarchar, isnull(dateBirth,'1900-01-01'), 23)

Приведение даты к строке в заданном формате:

select format(getdate(), 'dd.MM.yyyy HH:mm')

Полезные функции по работе с датами

select getdate() -- получить текущую дату

select dateadd(day, 7, getdate()) -- добавить 7 дней к дате

select dateadd(month, -2, getdate()) -- отнять 2 месяца от даты

select datediff(minute, date1, date2) -- получить разницу в минутах между date2 и date1

SELECT DAY(GETDATE())       -- 28  получить день даты (аналогично month, year, week)

SELECT DATENAME(month, GETDATE())       -- July получить название месяца 

SELECT DATEPART(month, GETDATE())       -- 7 получить часть даты (например, месяц, год или день)

SELECT DATEFROMPARTS(2017, 7, 28)       -- 2017-07-28  строит дату из частей

SELECT ISDATE('2017-07-28')     -- 1 - проверка является ли строка датой 

Полезные вычисления по датам (типовые задачи)

-- начало и конец недели
SET DATEFIRST 4   /* or use any other weird value to test it */
DECLARE @d DATETIME = GETDATE()
SELECT
  @d ThatDate,
  cast( DATEADD(dd, 0 - (@@DATEFIRST + 5 + DATEPART(dw, @d)) % 7, @d) as date) Monday,
  cast(DATEADD(dd, 6 - (@@DATEFIRST + 5 + DATEPART(dw, @d)) % 7, @d) as date) Sunday


-- начало месяца
SELECT DATEADD(month, DATEDIFF(month, 0, @d), 0) AS StartOfMonth

-- номер недели в году 
set datefirst 1;
select datepart(week, '2017-02-01');

-- получение дня недели
select datename(dw,getdate()) --Thursday
select datepart(dw,getdate()) --2

📲 Мы в MAX

#db

👉 @database_info

🧩 Сегодня покажу вам простой, но крайне полезный приём, как находить “тяжёлые” запросы в PostgreSQL, которые тормозят базу.

📌 Если у вас база под нагрузкой, и “что-то всё стало медленно”, первым делом проверьте:

SELECT pid, now() - query_start AS duration, query
FROM pg_stat_activity
WHERE state = 'active'
ORDER BY duration DESC
LIMIT 5;

Этот запрос показывает топ-5 самых долгих активных запросов. Обратите внимание на query_start - именно он поможет понять, кто завис и тормозит остальных.

А если хотите посмотреть историю медленных запросов за последние часы/дни - подключайте pg_stat_statements:

SELECT 
  calls, 
  total_time, 
  mean_time, 
  query 
FROM pg_stat_statements
ORDER BY total_time DESC
LIMIT 10;

🔍 Тут видно, какие запросы в сумме "съели" больше всего времени. И это гораздо честнее, чем смотреть только на mean_time или calls по отдельности.

💡Совет: подключите pg_stat_statements на проде и делайте такой анализ хотя бы раз в неделю. Это поможет находить проблемные места в приложении до того, как начнётся пожар.

📲 Мы в MAX

#db

👉 @database_info

🎯 Сегодня покажу простой способ ускорить запросы в PostgreSQL, даже не трогая сам SQL-код.

Часто вижу, как разработчики и админы оптимизируют запросы, играя с индексами или переписывая JOIN'ы. Но забывают про один мощный инструмент — ANALYZE.

ANALYZE обновляет статистику по таблицам. Эта статистика — хлеб для планировщика запросов. Если она устарела, PostgreSQL может выбрать неэффективный план, даже если у вас всё индексировано как надо.

👨‍🔧 Простой пример:

ANALYZE my_big_table;

Запускаешь — и вдруг сложный JOIN срабатывает в разы быстрее. Потому что PostgreSQL теперь знает, какие там объемы данных, сколько уникальных значений в колонках и т.п.

🧠 Совет: если ты регулярно заливаешь данные в таблицы (например, через ETL или бэкапы) — добавь ANALYZE в конец процедуры. Это дёшево, но может дать мощный прирост производительности.

Можно даже так:

VACUUM ANALYZE my_big_table;

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

📲 Мы в MAX

#db

👉 @database_info

🧩 Как сделать backup PostgreSQL с минимальной нагрузкой на прод?

Сегодня покажу один из самых эффективных способов бэкапа PostgreSQL — с помощью pg_basebackup + реплики.

Сценарий: у нас есть продовый PostgreSQL и настроенная горячая реплика (streaming replication). Зачем использовать реплику для бэкапа?

Причины:
- 💡 На проде бэкап может замедлить отклик приложения.
- 🔁 Реплика — отличный способ разгрузить основной сервер.
- ⏱ Бэкап с pg_basebackup возможен только на стопнутой БД или через репликацию.

Как сделать:

pg_basebackup -h replica.host -U repl_user -D /backup/pg -F tar -z -P

Пояснения:
- -h — адрес реплики
- -U — пользователь с правами репликации
- -D — куда класть бэкап
- -F tar -z — формат архива и сжатие
- -P — прогресс в консоли

Важно:
Пользователь repl_user должен быть прописан в pg_hba.conf и иметь роль REPLICATION.

А если добавить в cron, то получишь стабильный ночной бэкап без боли.

📲 Мы в MAX

#db

👉 @database_info

🚀 Сегодня покажу, как быстро диагностировать «тормоза» в PostgreSQL - без всяких внешних тулов и дополнительных логов. Только pg_stat_activity и немного здравого смысла.


Пользователи жалуются - "всё тормозит". Как понять, что именно? Открываем сессию в psql от суперпользователя и запускаем:

SELECT pid, state, wait_event_type, wait_event, query, now() - query_start AS duration
FROM pg_stat_activity
WHERE state != 'idle'
ORDER BY duration DESC;

📌 Что это нам даёт:
- Видим все активные (и зависшие) запросы.
- Сколько времени они уже выполняются (duration).
- На чём конкретно «висят»: CPU, IO, Lock, Client и т.д. (wait_event_type + `wait_event).

Пример:

wait_event_type: Lock
wait_event: relation

→ Сразу ясно: кто-то держит блокировку на таблицу, и все остальные ждут.


🔥Чтобы найти виновника, можно запустить:

SELECT blocked_locks.pid AS blocked_pid,
       blocking_locks.pid AS blocking_pid,
       blocked_activity.query AS blocked_query,
       blocking_activity.query AS blocking_query
FROM pg_locks blocked_locks
JOIN pg_locks blocking_locks ON blocked_locks.locktype = blocking_locks.locktype
  AND blocked_locks.database IS NOT DISTINCT FROM blocking_locks.database
  AND blocked_locks.relation IS NOT DISTINCT FROM blocking_locks.relation
  AND blocked_locks.page IS NOT DISTINCT FROM blocking_locks.page
  AND blocked_locks.tuple IS NOT DISTINCT FROM blocking_locks.tuple
  AND blocked_locks.transactionid IS NOT DISTINCT FROM blocking_locks.transactionid
  AND blocked_locks.classid IS NOT DISTINCT FROM blocking_locks.classid
  AND blocked_locks.objid IS NOT DISTINCT FROM blocking_locks.objid
  AND blocked_locks.objsubid IS NOT DISTINCT FROM blocking_locks.objsubid
  AND blocked_locks.pid != blocking_locks.pid
JOIN pg_stat_activity blocked_activity ON blocked_activity.pid = blocked_locks.pid
JOIN pg_stat_activity blocking_activity ON blocking_activity.pid = blocking_locks.pid
WHERE NOT blocked_locks.granted;

Этот запрос покажет, кто кого блокирует, и с каким запросом.

🙌 Это простая, но мощная техника диагностики. Помогала мне не раз в проде - особенно, когда времени мало, а багов много.

Ты пользуешься pg_stat_activity в проде? Или сразу лезешь в лог? Расскажи в комментах!

📲 Мы в MAX

#db

👉 @database_info

Как быстро найти “тяжёлые” запросы в PostgreSQL

Сегодня покажу простой способ найти самые ресурсоёмкие запросы, которые прямо сейчас выполняются в PostgreSQL. Это помогает, когда база начинает “тормозить”, а понять почему - сложно.

Используем pg_stat_activity и pg_stat_statements. Но сначала убедись, что pg_stat_statements включён:

-- Проверка:
SELECT * FROM pg_extension WHERE extname = 'pg_stat_statements';

-- Включение (если не установлен):
CREATE EXTENSION pg_stat_statements;

Теперь сам запрос на поиск “тяжёлых” запросов:

SELECT
query,
calls,
total_exec_time,
mean_exec_time,
rows
FROM
pg_stat_statements
ORDER BY
total_exec_time DESC
LIMIT 5;

А если интересует то, что прямо сейчас выполняется — тогда так:

SELECT
pid,
now() - query_start AS duration,
state,
query
FROM
pg_stat_activity
WHERE
state != 'idle'
ORDER BY
duration DESC;

Я часто сохраняю эти запросы в отдельный .sql-файл, чтобы запускать сразу при проблемах с производительностью. Полезно добавить в .psqlrc алиас или даже обернуть в скрипт.

Как вы ищете “тяжёлые” запросы в проде? Поделитесь в комментариях.

📲 Мы в MAX

#db

👉 @database_info

Будьте осторожны при подсчете строк из outer join

COUNT (*) => строки в группе; всегда хотя бы одна
COUNT ( inner_tab_col ) => строки из внутренней таблицы; ноль, если нет совпадений.

Это происходит потому, что COUNT ( col ) добавляет только ненулевые значения.

Убедитесь, что inner_tab_col является обязательным!

📲 Мы в MAX

#db

👉 @database_info

🧵 Сегодня я покажу вам простой, но мощный способ отладки сложных SQL-запросов

Когда у вас в проекте появляется монструозный запрос с десятками джойнов, подзапросов и оконных функций — ловить ошибки становится больно. Но есть подход, который реально спасает: инкрементальная отладка.

💡 Суть: разбиваем запрос на небольшие части и поочередно проверяем каждую

Вот как это делаю я:

1. Начинаю с ядра - самого внутреннего подзапроса или CTE. Проверяю, что он возвращает ожидаемые данные.
2. Добавляю следующий уровень логики - джойны, условия, группировки. Каждый раз выполняю и проверяю результат.
3. Для удобства использую WITH (CTE) - это даёт имена промежуточным результатам и делает запрос читабельным.
4. Сложные выражения и агрегаты выношу в отдельные CTE - это помогает быстрее изолировать проблему.
5. Если запрос очень тяжёлый - сохраняю промежуточные результаты в временные таблицы.

🔥 PostgreSQL позволяет использовать EXPLAIN (ANALYZE, BUFFERS) для профилирования на каждом этапе. Очень помогает найти, где тормозит.


📲 Мы в MAX

#db

👉 @database_info

⚠️ Антипаттерн: использовать NULL без оглядки

На первый взгляд NULL — это просто “нет значения”. Но в реальности — это тихий саботаж:

🔸 NULL != NULL. Да-да, сравнение NULL = NULL даст false или unknown. Это ломает привычную логику и может убить фильтры.

🔸 Агрегации ведут себя странно. COUNT(column) не считает NULL'ы. AVG, SUM — тоже их игнорируют. Итог: неверная статистика.

🔸 Индексы и WHERE column IS NULL. Не все СУБД эффективно используют индексы при таких запросах. Можно словить тормоза.

🔸 NOT IN + NULL = 💥. Запрос WHERE id NOT IN (subquery) может вернуть пустой результат, если в подзапросе есть хотя бы один NULL.

💡 Как избежать проблем:

1. Всегда осознанно работай с NULL — используй IS NULL и IS NOT NULL, не = и !=.
2. По возможности избегай NULL в колонках, где это не нужно. Лучше использовать значения по умолчанию.
3. Добавляй проверки в коде: COALESCE, IFNULL, NVL и аналоги.
4. Понимай, как твоя СУБД работает с NULL в индексах и фильтрах.

🎯 Вывод: NULL — не пустота, а “неизвестность”. Обращайся с ним осторожно, иначе баги будут неявными и неприятными.

Сохрани, чтобы не отловить баг на проде 🐛

📲 Мы в MAX

#db

👉 @database_info

Транзакции в SQLite: просто, но со своими нюансами

SQLite - это встраиваемая база данных, и она немного отличается от привычных серверных СУБД (PostgreSQL, MySQL) в части работы с транзакциями. Но транзакции там есть, и работают по принципу ACID - атомарность, согласованность, изолированность и долговечность.

Разберёмся по полочкам:


🔹 Как начинается и заканчивается транзакция?

BEGIN TRANSACTION;
-- какие-то запросы
COMMIT;

Или, в случае ошибки:

ROLLBACK;

Можно использовать синонимы:
- BEGIN = BEGIN DEFERRED
- BEGIN IMMEDIATE
- BEGIN EXCLUSIVE

Они отличаются уровнем блокировок.


🔹 Типы транзакций

1. DEFERRED (по умолчанию)
🔒 Блокировки ставятся только при первом доступе к таблице (на чтение/запись).

2. IMMEDIATE
🔒 Сразу ставит блокировку на запись (write-lock). Полезно, если точно знаешь, что будешь писать — исключишь гонки.

3. EXCLUSIVE
🔒 Блокирует БД полностью. Даже другие чтения не пройдут.


🔹 Особенности SQLite

- Одна запись за раз: SQLite поддерживает одновременные чтения, но только одну запись одновременно. Остальные получат "database is locked".
- Авто-коммиты: если явно не начать транзакцию - SQLite будет делать коммит после каждого запроса.
- Журналирование: SQLite использует WAL (write-ahead log) или rollback journal - в зависимости от настроек. WAL - более производителен для параллельного чтения.


💡 Советы

- При пакетной вставке всегда оборачивай в транзакцию:

BEGIN;
INSERT INTO users VALUES (...);
INSERT INTO users VALUES (...);
...
COMMIT;

→ Это в разы быстрее, чем отдельные INSERT с автокоммитом.

- Если получаешь ошибку database is locked, проверь:
- Не оставил ли ты открытые транзакции
- Не работают ли несколько процессов с БД одновременно без координации


Сохрани, чтобы не потерять!

📲 Мы в MAX

#db

👉 @database_info

🐘 Открыт прием заявок на выступления для специалистов по PostgreSQL

Мероприятие: PG BootCamp Russia — официальное российское комьюнити-мероприятие PostgreSQL
Когда: весна 2026 г. (дата уточняется)
Где: г. Москва
Больше о мероприятиях PG BootCamp

В отличие от коммерческих конференций, предметом докладов выступает «ванильная» версия этой СУБД. Темы выступлений, связанные с коммерческими продуктами, не принимаются. Доклады (их обычно до 16 в два трека) делятся по темам разработки и эксплуатации. Формат предполагает камерную атмосферу, максимальную практическую пользу и содержательное профессиональное общение.

Открыт прием заявок на выступления:

🔹Исследование внутренней архитектуры PostgreSQL
🔹 Оптимизация производительности в высоконагруженных системах
🔹Анализ сложных задач и методов их решения
🔹 Инструменты и методологии для DBA
🔹 R&D-исследования, связанные с Postgres

Если у вас есть материалы, которым вы хотите поделиться с сообществом, — пожалуйста, присылайте тезисы. Это возможность не только представить свою работу, но и получить содержательную обратную связь от ведущих специалистов.

🎙Подать заявку на выступление