Разбираем почему REINDEX не заменяет VACUUM в PostgreSQL!

После большого количества операций UPDATE и DELETE в PostgreSQL часто используют команды VACUUM и REINDEX. Несмотря на то что обе относятся к обслуживанию базы данных, они решают разные задачи и не являются взаимозаменяемыми.

Создадим таблицу:

CREATE TABLE users (
    id SERIAL PRIMARY KEY,
    email TEXT
);

Добавим данные:

INSERT INTO users (email)
SELECT 'user' || g || '@mail.com'
FROM generate_series(1, 100000) AS g;

Удалим половину строк:

DELETE
FROM users
WHERE id <= 50000;

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

Для их обработки используется:

VACUUM users;

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

При этом обычный VACUUM обычно не уменьшает размер файла таблицы на диске — освободившееся место остаётся внутри таблицы и используется последующими операциями INSERT и UPDATE. Теперь перестроим индекс:

REINDEX INDEX users_pkey;

Или сразу все индексы таблицы:

REINDEX TABLE users;

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

При этом REINDEX не очищает таблицу от мёртвых версий строк и не заменяет выполнение VACUUM. Если же необходимо физически уменьшить размер таблицы и вернуть свободное место операционной системе, используется другая команда:

VACUUM FULL users;

VACUUM FULL полностью переписывает таблицу в новый компактный файл, освобождает место на диске, но требует блокировку уровня ACCESS EXCLUSIVE, поэтому на время выполнения таблица становится недоступной для чтения и записи.

Важно понимать, что в большинстве случаев регулярное обслуживание выполняет autovacuum. Ручной запуск VACUUM, VACUUM FULL или REINDEX обычно является следствием анализа конкретной проблемы, а не стандартной процедурой после большого количества изменений данных.

🔥 Главное отличие: VACUUM обслуживает таблицу и связанные с ней индексы, освобождая пространство, занятое мёртвыми версиями строк, для повторного использования. REINDEX занимается исключительно перестроением индексов. Эти команды решают разные задачи и используются в разных ситуациях.

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

👨‍💻 Мега информативная статья на Хабре: «Что мы находим при аудите PostgreSQL: 10 распространенных ошибок»!

В этой статье:
• Разбираются реальные проблемы, которые DBA чаще всего находят при проверке PostgreSQL в продакшене;
• Показывается, почему бэкапы могут оказаться бесполезными, а широкие права, открытый доступ и отсутствие логов создают серьезные риски;
• Разбираются настройки производительности, долгие транзакции, BLOAT, автовакуум и архитектурные ошибки, которые могут привести к сбоям.

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

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

📂 Как SQL-запрос выполняется внутри СУБД!

От отправки запроса до результата SQL проходит несколько этапов: парсинг, оптимизация, построение плана выполнения, доступ к данным, кэширование и управление транзакциями.

На схеме — архитектура обработки SQL-запроса и основные компоненты базы данных.

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

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

👨‍💻 Yandex Cloud — инженерные материалы по SQL и базам данных!

На сайте собраны статьи и документация по работе с базами данных и SQL. Материалы помогают разобраться не только с написанием запросов, но и с тем, как работают внутренние механизмы СУБД: транзакции, индексы, оптимизация запросов, распределённые базы данных и эксплуатация систем.

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

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

📂 Git Fundamentals: шпаргалка по основным операциям и workflow!

Разобраны основные элементы Git-экосистемы: структура репозитория, работа с индексом (staging area), создание коммитов, управление ветками, слияние изменений, взаимодействие с remote-репозиториями и основные команды для ежедневной разработки.

На картинке — визуальное представление Git workflow, жизненный цикл изменений от рабочей директории до удалённого репозитория, а также базовые операции commit, branch, merge, fetch, pull и push.

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

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

🧐 Материалы по базам данных — информатвный набор для изучения SQL и СУБД!

Большая подборка учебных материалов по базам данных: книги, лекции, лабораторные работы и задания по SQL, PostgreSQL и Microsoft SQL Server. Внутри собраны материалы по ключевым темам, которые нужны разработчику при работе с базами данных: основы реляционной модели и проектирования БД, нормализация данных и ограничения (constraints), агрегатные функции, JOIN, подзапросы и др.

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

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

Сравнивайте несколько колонок как одно значение!

В PostgreSQL необязательно расписывать сравнение нескольких полей через длинные цепочки AND и OR. Можно использовать row constructor comparison — сравнить сразу кортежи значений.

Например, условие для keyset pagination часто пишут так:

WHERE user_id > :user_id
   OR (user_id = :user_id AND id > :id)

Но PostgreSQL умеет выразить то же самое напрямую:

WHERE (user_id, id) > (:user_id, :id)
ORDER BY user_id, id
LIMIT 100;

Сравнение идёт слева направо: сначала user_id, а если значения равны — id. Поэтому конструкция естественно совпадает с лексикографическим порядком составного ORDER BY.

И это не просто сокращение синтаксиса. Под такой запрос можно сделать обычный составной B-tree индекс:

CREATE INDEX orders_user_id_id_idx
ON orders (user_id, id);

Тот же приём работает с диапазонами составных ключей:

WHERE (year, month) >= (2026, 4)
  AND (year, month) <  (2027, 1)

🔥 Row comparison позволяет заменить громоздкую булеву логику сравнением кортежей и особенно хорошо ложится на keyset pagination и составные B-tree индексы. Важно только помнить про NULL: обычные сравнения с ним могут дать UNKNOWN.

➡️ SQL Ready | #совет

👨‍💻 Наткнулся на интересную статью на Хабре: «Реализация автоудаления блокирующих сессий в MS SQL»!

В этой статье:
• Разбирается механизм поиска корневых блокирующих сессий с помощью системных представлений MS SQL Server;
• Показывается, как реализовать автокиллер на T-SQL с логированием, анализом цепочек блокировок и безопасным удалением зависших транзакций;
• Объясняется, как автоматизировать мониторинг блокировок через SQL Server Agent и сохранить историю для последующего анализа.

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

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

📂 Напоминалка по возможностям PostgreSQL!

Например, PostgreSQL отлично подходит не только для обычных CRUD-приложений (OLTP), но и для аналитики (OLAP), работы с геоданными, временными рядами, распределёнными таблицами и интеграции с внешними источниками данных через Foreign Data Wrapper (FDW).

На картинке — обзор основных направлений применения PostgreSQL и популярных расширений.

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

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

🧐 Шпаргалка по оконным функциям SQL с примерами!

Полезный материал для тех, кто хочет разобраться с оконными функциями SQL и научиться применять их в запросах. Здесь объясняется, чем оконные функции отличаются от обычной агрегации, как устроена конструкция OVER и как работать с отдельными группами строк без их объединения.

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

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

📂 Напоминалка по проектированию систем (System Design)!

Например, Load Balancing распределяет нагрузку между сервисами, Caching ускоряет доступ к данным, а Replication и Sharding помогают масштабировать базы данных.

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

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

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

🧐 Крутая статья лежит на Хабре: «Avalon: как построить эффективный Feature Store на YDB»!

В этой статье:
• Разбирается архитектура Avalon — масштабируемого Feature Store для централизованного хранения и быстрого получения миллиардов признаков;
• Показывается, как с помощью YDB организованы шардирование, точечные и batch-запросы, импорт данных, ACL и Change Data Capture;
• Рассказывается, какие архитектурные решения позволяют системе работать с 6,5 млрд ключей и выдерживать до 100 тысяч RPS на чтение при P95 около 5 мс.


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

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

📂 Напоминалка по SQL JOIN!

Например, SEMI JOIN позволяет получить строки, для которых есть совпадение в другой таблице, ANTI JOIN — найти строки без совпадений, а NATURAL JOIN автоматически соединяет таблицы по одноимённым столбцам.

На картинке — наглядное сравнение трёх подходов: SEMI JOIN через EXISTS, ANTI JOIN через NOT EXISTS и NATURAL JOIN, а также показано, чем SEMI JOIN отличается от обычного INNER JOIN.

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

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

Временные таблицы: различия между TEMP, CTE и материализацией данных!

В SQL существует несколько способов работать с промежуточными результатами. Основные варианты — временные таблицы, CTE через WITH и обычные подзапросы. Выбор между ними влияет на читаемость запроса, возможность повторного использования данных и работу оптимизатора.

Временная таблица создаётся внутри текущей сессии базы данных и существует до её завершения или до явного удаления. Она подходит для многоэтапной обработки данных, когда результат нужно использовать в нескольких следующих запросах.

CREATE TEMP TABLE monthly_sales AS
SELECT
    customer_id,
    SUM(amount) AS total_amount
FROM orders
WHERE created_at >= '2026-01-01'
GROUP BY customer_id;

После создания временная таблица становится отдельным объектом базы данных. К ней можно обращаться как к обычной таблице, создавать индексы и выполнять дополнительные операции.

SELECT *
FROM monthly_sales
WHERE total_amount > 10000;

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

CREATE INDEX idx_monthly_sales_customer_id
ON monthly_sales(customer_id);

CTE (Common Table Expression) создаётся с помощью конструкции WITH и существует только во время выполнения одного SQL-запроса. Он помогает сделать сложную логику более читаемой и структурированной.

WITH monthly_sales AS (
    SELECT
        customer_id,
        SUM(amount) AS total_amount
    FROM orders
    GROUP BY customer_id
)
SELECT *
FROM monthly_sales
WHERE total_amount > 10000;

В PostgreSQL начиная с версии 12 CTE может быть автоматически встроен оптимизатором в основной запрос. Это называется CTE inlining. В таком случае отдельное промежуточное хранилище данных не создаётся.

WITH active_users AS MATERIALIZED (
    SELECT *
    FROM users
    WHERE status = 'active'
)
SELECT *
FROM active_users;

Основное отличие MATERIALIZED заключается в том, что PostgreSQL принудительно сохраняет результат CTE перед дальнейшей обработкой. Это может быть полезно, если один и тот же результат используется несколько раз или нужно избежать повторного выполнения тяжёлого вычисления.

WITH user_stats AS MATERIALIZED (
    SELECT
        user_id,
        COUNT(*) AS orders_count
    FROM orders
    GROUP BY user_id
)
SELECT
    a.user_id,
    a.orders_count
FROM user_stats a
JOIN user_stats b
    ON a.user_id = b.user_id;

Однако использование CTE не всегда означает материализацию. PostgreSQL самостоятельно выбирает оптимальный способ выполнения запроса, если не указано MATERIALIZED или NOT MATERIALIZED.

WITH user_stats AS NOT MATERIALIZED (
    SELECT
        user_id,
        COUNT(*) AS orders_count
    FROM orders
    GROUP BY user_id
)
SELECT *
FROM user_stats;

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

CREATE TEMP TABLE user_stats AS
SELECT
    user_id,
    COUNT(*) AS orders_count
FROM orders
GROUP BY user_id;

CREATE INDEX idx_user_stats_user_id
ON user_stats(user_id);

ANALYZE user_stats;

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

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

SELECT *
FROM (
    SELECT
        user_id,
        COUNT(*) AS orders_count
    FROM orders
    GROUP BY user_id
) s
WHERE orders_count > 50;

🔥 Выбор подходящего варианта зависит от задачи. CTE обычно используют для повышения читаемости и разделения сложной логики внутри одного запроса. Временные таблицы подходят для многошаговой обработки, больших промежуточных результатов и случаев, когда нужны индексы. Подзапросы удобны для простых локальных вычислений внутри одного SQL-выражения.

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

👨‍💻 Koddo — сайт с теорией и практикой для обучения!

Платформа для изучения SQL через решение реальных задач прямо в браузере. На практике разбираются выборки и фильтрация, GROUP BY и HAVING, JOIN, работа с датами, подзапросы, CTE и оконные функции. Решения автоматически проверяются, а AI-ассистент может дать подсказку, не раскрывая готовый ответ.

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

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