Что такое VACUUM FULL в SQL?

Что такое VACUUM FULL в SQL?

VACUUM FULL — это команда в системах управления базами данных (СУБД), таких как PostgreSQL, предназначенная для полной очистки и реорганизации таблицы, включая возврат неиспользуемого дискового пространства операционной системе. Это расширенная версия стандартной команды VACUUM, выполняющая более агрессивную уборку "мертвых" (удалённых или обновлённых) строк.

Основная проблема, которую решает VACUUM

В PostgreSQL и других СУБД, использующих многовариантность управления параллелизмом (MVCC), операторы UPDATE и DELETE не удаляют данные физически сразу. Вместо этого:

• UPDATE создаёт новую версию строки, а старая помечается как недействительная.
• DELETE помечает строку как удалённую.

Эти устаревшие версии строк называются "мертвыми кортежами" (dead tuples). Они остаются в таблице, пока не будут очищены автовакуумом (autovacuum) или ручной командой VACUUM. Обычный VACUUM освобождает пространство внутри таблицы для повторного использования, но не возвращает его операционной системе.

Как работает VACUUM FULL?

VACUUM FULL идет значительно дальше:

1. Создаёт новую, компактную копию таблицы, включая только "живые" (актуальные) данные.
2. Перестраивает все индексы для этой новой таблицы.
3. Удаляет старую версию таблицы и возвращает освобождённое дисковое пространство ОС.

Ключевое отличие: VACUUM — это "подметание пола" (очистка мусора внутри таблицы), а VACUUM FULL — это "переезд в новую, меньшую квартиру" (полная реорганизация).

Синтаксис и пример использования

-- Базовая форма для одной таблицы
VACUUM FULL table_name;

-- Для всей базы данных (требует прав суперпользователя)
VACUUM FULL;

-- С дополнительными параметрами
VACUUM (FULL, ANALYZE, VERBOSE) orders;

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

Когда использовать VACUUM FULL?

• Значительное увеличение размера таблицы после массовых UPDATE/DELETE.
• Нехватка дискового пространства на сервере.
• Сильная фрагментация таблицы, ведущая к деградации производительности (хотя это случается реже, чем многие думают).
• Перед выполнением важных резервных копий или миграций для минимизации занимаемого места.

Критические недостатки и предостережения

1. Блокировка таблицы (EXCLUSIVE LOCK): На время выполнения VACUUM FULL таблица полностью блокируется для любых операций записи и, в зависимости от СУБД, для чтения. Это простой (downtime) для приложения.
2. Высокие ресурсозатраты: Процесс требует удвоенного дискового пространства (старая и новая копии) и значительных вычислительных ресурсов.
3. Не всегда нужен: В большинстве случаев обычного VACUUM или autovacuum достаточно. Постоянная необходимость в VACUUM FULL часто указывает на проблемы с архитектурой приложения.

Альтернативы в PostgreSQL

Для крупных продакшен-таблиц предпочтительнее использовать утилиты, которые делают работу поэтапно с минимальной блокировкой:

• pg_repack: Сторонняя утилита, которая логически воссоздает таблицу, позволяя выполнять операции чтения и записи практически всё время работы.
• pg_squeeze: Ещё один инструмент для реорганизации таблиц "на лету".

Пример сравнения работы VACUUM и VACUUM FULL

-- Проверим размер таблицы и индекс до операции
SELECT pg_size_pretty(pg_total_relation_size('orders')) as total_size;

-- Массовое обновление данных, создающее множество мертвых кортежей
UPDATE orders SET status = 'processed' WHERE status = 'new';

-- Обычный VACUUM: освобождает место для повторного использования внутри таблицы
VACUUM ANALYZE orders;
-- Размер таблицы на диске, скорее всего, не уменьшится

-- VACUUM FULL: радикально уменьшает физический размер
VACUUM FULL orders;
-- Размер таблицы на диске станет близок к размеру только актуальных данных

Вывод: VACUUM FULL — это мощный, но деструктивный и блокирующий инструмент. Его применение должно быть обоснованным, спланированным и выполняться в период минимальной нагрузки на базу данных. Для регулярного обслуживания следует полагаться на настройку autovacuum, а к VACUUM FULL прибегать лишь в исключительных случаях после тщательного анализа. В высоконагруженных системах всегда рассматривайте альтернативы, такие как pg_repack.