UNIQUE и NULL в PostgreSQL 15!

До PostgreSQL 15 уникальные ограничения считали NULL разными значениями. Это означало, что таблица спокойно принимала сколько угодно строк с NULL, даже если на колонке стоял UNIQUE.

CREATE TABLE users (
    email text UNIQUE
);

INSERT INTO users VALUES (NULL);
INSERT INTO users VALUES (NULL);

Обе вставки выполнятся успешно.

Если NULL тоже должен быть уникальным, приходилось придумывать обходные пути. Кто-то делал частичные индексы, кто-то использовал COALESCE(), кто-то заводил отдельные флаги.

CREATE TABLE users (
    email text,
    CONSTRAINT users_email_key
        UNIQUE NULLS NOT DISTINCT (email)
);

INSERT INTO users VALUES (NULL);
INSERT INTO users VALUES (NULL);

Вторая вставка уже завершится ошибкой. Для ограничения NULL считается таким же значением, как и любой другой ключ.

CREATE TABLE users (
    tenant_id int,
    email text,
    CONSTRAINT uq_user
        UNIQUE NULLS NOT DISTINCT (tenant_id, email)
);

Полезно, когда NULL — это полноценное значение предметной области, а не просто "неизвестно".

🔥 Небольшая возможность PostgreSQL 15, которая позволяет удалить сразу несколько старых костылей вокруг UNIQUE.

➡️ SQL Ready | #совет

🤔 SQL Lab — интерактивная платформа для изучения и практики SQL!

Сайт для тех, кто хочет освоить SQL через работу с запросами. Код пишется прямо в браузере: выполняете запрос, сразу видите результат и получаете автоматическую проверку решения. Обучение построено от базовых SELECT и ORDER BY до JOIN, подзапросов, транзакций, индексов, оптимизации запросов и PostgreSQL. Есть структурированные курсы с теорией и практикой.

📌 Оставляю ссылочку: sqllab.ru

➡️ SQL Ready | #ресурс

Научите оптимизатор понимать ваши данные!

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

Например, если city = 'Paris', то country почти всегда будет 'France'. Без этой информации оптимизатор может сильно ошибиться при оценке количества строк и выбрать неудачный план.

EXPLAIN
SELECT *
FROM users
WHERE country = 'France'
  AND city = 'Paris';

Вместо того чтобы сразу создавать новый индекс, попробуйте расширенную статистику.

CREATE STATISTICS users_dep (dependencies)
ON country, city
FROM users;

ANALYZE users;

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

🔥 Если запрос фильтрует по нескольким связанным колонкам и оптимизатор ошибается в оценке, сначала попробуйте CREATE STATISTICS, а уже потом решайте, нужен ли новый индекс.

➡️ SQL Ready | #совет

📂 Шпаргалка по Backend-разработке!

Например, REST используется для построения API, Redis помогает кэшировать данные, а Docker позволяет упаковать приложение вместе со всеми его зависимостями.

На картинке — основные направления Backend-разработки: языки программирования, базы данных, API, авторизация, серверы, контейнеризация, CI/CD и мониторинг. Полезная карта того, что стоит изучить Backend-разработчику.

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

➡️ SQL Ready | #ресурс

Почему коррелированные подзапросы могут снижать производительность SQL-запроса!

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

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

SELECT
    u.id,
    u.name,
    (
        SELECT SUM(o.amount)
        FROM orders o
        WHERE o.user_id = u.id
    ) AS total_amount
FROM users u;

Если users содержит миллион строк, подзапрос потенциально может быть выполнен миллион раз. Даже при наличии индекса по orders.user_id такой подход иногда становится менее эффективным, особенно в сложных отчётах.

Часто можно сначала агрегировать данные, а затем присоединить результат:

SELECT
    u.id,
    u.name,
    COALESCE(o.total_amount, 0) AS total_amount
FROM users u
LEFT JOIN (
    SELECT
        user_id,
        SUM(amount) AS total_amount
    FROM orders
    GROUP BY user_id
) o
ON o.user_id = u.id;

Здесь агрегация выполняется один раз, после чего результат соединяется с таблицей пользователей.

Но это не универсальное правило. Современные оптимизаторы умеют преобразовывать некоторые коррелированные подзапросы в более эффективные планы выполнения, поэтому всегда нужно смотреть реальный план через EXPLAIN / EXPLAIN ANALYZE.

Для получения последнего заказа пользователя часто используют оконные функции:

SELECT
    user_id,
    created_at
FROM (
    SELECT
        user_id,
        created_at,
        ROW_NUMBER() OVER (
            PARTITION BY user_id
            ORDER BY created_at DESC
        ) AS rn
    FROM orders
) t
WHERE rn = 1;

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

(user_id, created_at DESC)

коррелированный запрос вида:

SELECT ...
FROM orders
WHERE user_id = ?
ORDER BY created_at DESC
LIMIT 1;

может быть быстрее, потому что база сможет быстро найти одну нужную строку через индекс.

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

🔥 В больших отчётах и высоконагруженных API всегда проверяйте фактический план выполнения. Иногда JOIN, предварительная агрегация или оконные функции позволяют значительно уменьшить количество лишних операций.

➡️ SQL Ready | #практика

✍️ Архитектура высоконагруженных систем — подробный материал по проектированию Highload!

Здесь разобраны ключевые вещи, с которыми сталкиваются при разработке нагруженных систем: RPS, latency и throughput, вертикальное и горизонтальное масштабирование, индексы, репликация и шардирование баз данных, кеширование, брокеры сообщений и др. Есть практические примеры с MySQL, PostgreSQL, Kafka и Tarantool, а также инструменты для тестирования и мониторинга.

Оставляю ссылочку: GitHub 📱

➡️ SQL Ready | #репозиторий

🐱 Нашел крайне занимательную статью на Хабре: «Условная агрегация в SQL: ускоряем отчеты, избавляясь от лишних JOIN-ов и подзапросов»!

В этой статье:
• Узнаете, как ускорять сложные SQL-запросы с помощью условной агрегации;
• Разберёте применение CASE и FILTER вместо множества подзапросов и JOIN-ов;
• Посмотрите на примерах, как сделать SQL-код быстрее, чище и проще для поддержки.

🔊 Продолжай читать на Habr!

➡️ SQL Ready | #статья

Почему ctid нельзя использовать как постоянный идентификатор!

В PostgreSQL каждая строка имеет системную колонку ctid. Она содержит физический адрес текущей версии строки в таблице: номер страницы и позицию строки внутри этой страницы.

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

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

CREATE TABLE users (
    id INTEGER GENERATED ALWAYS AS IDENTITY PRIMARY KEY,
    name TEXT
);

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

INSERT INTO users (name)
VALUES
('Alice'),
('Bob'),
('Charlie');

Посмотрим, какое значение ctid PostgreSQL присвоил каждой записи после вставки.

SELECT
    ctid,
    id,
    name
FROM users;

Результат может выглядеть так:

ctid  | id | name
------+----+--------
(0,1) | 1  | Alice
(0,2) | 2  | Bob
(0,3) | 3  | Charlie

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

UPDATE users
SET name = 'Robert'
WHERE id = 2;

После выполнения UPDATE снова посмотрим значения ctid и сравним их с предыдущим результатом.

SELECT
    ctid,
    id,
    name
FROM users;

Теперь можно увидеть, что значение ctid изменилось. Например:

ctid  | id | name
------+----+---------
(0,1) | 1  | Alice
(0,4) | 2  | Robert
(0,3) | 3  | Charlie

Это происходит из-за механизма MVCC. При выполнении UPDATE PostgreSQL не изменяет строку на месте, а создаёт её новую версию, которая получает новый физический адрес (ctid). Старая версия строки некоторое время остаётся в таблице и может быть видима другим транзакциям в зависимости от их снимка данных.

Изменение ctid происходит не только при UPDATE. Любые операции, которые физически переписывают таблицу, также приводят к изменению физических адресов строк. Например:

VACUUM FULL users;

или

CLUSTER users USING users_pkey;

Поэтому использовать ctid в качестве внешнего ключа, хранить его в приложении или считать постоянным идентификатором записи нельзя.
При этом ctid остаётся полезным инструментом для служебных задач. Один из самых распространённых случаев — удалить одну запись среди полностью одинаковых дубликатов, когда значения всех пользовательских столбцов совпадают и отличить строки обычными средствами невозможно.

Например, создадим отдельную таблицу без ограничений уникальности:

CREATE TABLE duplicate_users (
    name TEXT
);

Добавим одинаковые строки:

INSERT INTO duplicate_users (name)
VALUES
('Alice'),
('Alice'),
('Bob');

Удалим только одну из двух одинаковых строк:

DELETE
FROM duplicate_users
WHERE ctid = (
    SELECT ctid
    FROM duplicate_users
    WHERE name = 'Alice'
    LIMIT 1
);

В результате останется одна строка с именем Alice. В этом примере ctid определяется и используется в рамках одного SQL-запроса, поэтому используется актуальный физический адрес версии строки и не возникает проблемы с использованием устаревшего значения.

🔥 ctid — это физический адрес текущей версии строки, а не её постоянный идентификатор. Для связи данных всегда используйте первичный ключ, а ctid оставьте для диагностических и служебных операций.

➡️ SQL Ready | #практика

😍 zasqlpython — платформа для изучения и практики SQL!

Сайт позволяет изучать SQL с нуля и сразу закреплять материал на практике. Бесплатный курс включает 10 уроков и 92 задачи с автоматической проверкой прямо в браузере. После базового курса можно перейти к SQL-тренажёру с сотнями задач повышенной сложности и заданиями в формате собеседований.

📌 Оставляю ссылочку: zasqlpython.ru

➡️ SQL Ready | #ресурс

📂 Шпаргалка по снижению Latency в Backend-системах!

Например, Cache позволяет отдавать часто используемые данные без обращения к базе данных, а Load Balancer распределяет запросы между несколькими серверами, повышая скорость и отказоустойчивость приложения.

На картинке — основные стратегии уменьшения задержек в высоконагруженных системах.

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

➡️ SQL Ready | #ресурс

Почему OFFSET деградирует на больших таблицах!

OFFSET часто используют для пагинации, потому что запрос выглядит просто. На небольших таблицах проблем обычно нет, но на больших объёмах стоимость такого подхода растёт вместе с глубиной страницы.

Есть таблица:

events(
    id BIGINT,
    user_id BIGINT,
    payload JSONB,
    created_at TIMESTAMPTZ
)

Типичная пагинация:

SELECT
    id,
    user_id,
    created_at
FROM events
ORDER BY created_at DESC
LIMIT 50 OFFSET 1000000;

Кажется, что база должна просто пропустить миллион строк и вернуть следующие 50. Но SQL-движок не может сделать настоящий прыжок через OFFSET. Ему нужно обработать строки до нужной позиции, а потом отбросить их.

Без подходящего индекса это может выглядеть так: база читает строки, определяет порядок сортировки, обрабатывает OFFSET + LIMIT записей, выбрасывает ненужные строки и возвращает только нужный результат.

Даже если есть индекс:

CREATE INDEX idx_events_created_at
ON events(created_at DESC);

ситуация всё равно не идеальна.

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

Например:

LIMIT 50 OFFSET 1000000;

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

Для глубоких страниц обычно используют keyset pagination (cursor pagination). Вместо номера страницы передаётся последнее значение из предыдущего результата:

SELECT
    id,
    user_id,
    created_at
FROM events
WHERE created_at < '2026-08-01 12:00:00'
ORDER BY created_at DESC
LIMIT 50;

Теперь база может использовать индекс и сразу искать позицию, с которой нужно продолжить чтение.

Но одного created_at недостаточно, если несколько событий имеют одинаковое время.

Например:

2026-08-01 12:00:00

2026-08-01 12:00:00

2026-08-01 12:00:00

Порядок становится неоднозначным. Поэтому добавляют уникальный ключ:

CREATE INDEX idx_events_cursor
ON events(created_at DESC, id DESC);

И запрос становится:

SELECT
    id,
    user_id,
    created_at
FROM events
WHERE (created_at, id) < ('2026-08-01 12:00:00', 1500000)
ORDER BY created_at DESC, id DESC
LIMIT 50;

Теперь курсор точно определяет позицию в индексе.

Главное преимущество такого подхода — стоимость запроса зависит в основном от размера страницы, а не от глубины пагинации. Первая страница:

LIMIT 50;

и страница после миллионов записей:

WHERE (created_at, id) < (...)
LIMIT 50;

используют один и тот же принцип: найти позицию в B-tree индексе и продолжить чтение.

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

🔥 Делаем вывод: OFFSET удобен для разработки, но плохо масштабируется на больших объёмах данных. Для больших таблиц лучше использовать keyset pagination с составным индексом и стабильным курсором.

➡️ SQL Ready | #практика

✍️ Попалась интересная статья на Хабре: «Почему в БД на PostgreSQL популярен тип numeric?»!

В этой статье:
• Разберётесь, почему для денег и точных расчётов часто выбирают numeric, несмотря на его производительность;
• Узнаете, чем на практике отличаются numeric, целые типы и double precision;
• Посмотрите, какие требования к точности и округлению предъявляют SQL, платёжные системы и финансовые стандарты.

🔊 Продолжай читать на Habr!

➡️ SQL Ready | #статья

Настройки только для одного запроса!

Необязательно менять statement_timeout, work_mem или другие параметры для всей сессии. SET LOCAL действует только до конца текущей транзакции.

BEGIN;

SET LOCAL lock_timeout = '500ms';

ALTER TABLE orders
ADD COLUMN source text;

COMMIT;

Так миграция не будет бесконечно ждать блокировку: если таблица занята дольше заданного времени, PostgreSQL завершит операцию ошибкой.

BEGIN;

SET LOCAL work_mem = '512MB';

SELECT customer_id, count(*)
FROM events
GROUP BY customer_id;

COMMIT;

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

🔥 SET LOCAL позволяет тюнить PostgreSQL под конкретную операцию и автоматически возвращает настройки назад после COMMIT или ROLLBACK.

➡️ SQL Ready | #совет

😎 PostgreSQL FAQ — справочник по частым проблемам и вопросам!

Здесь собраны разборы типичных ситуаций при работе с PostgreSQL: проблемы с подключением и настройкой, ошибки в SQL, оптимизация медленных запросов, партиционирование, размеры таблиц, timestamp with time zone, pg_dump и другие нюансы. Есть конкретные команды, примеры диагностики и рекомендации по тому, какие данные собирать для поиска проблем.

Оставляю ссылочку: GitHub 📱

➡️ SQL Ready | #репозиторий