Архивирование таблиц – это процесс перемещения устаревших или редко используемых данных из «рабочих» таблиц в специальные архивные хранилища. Правильный подход к архивированию позволяет снизить нагрузку на СУБД, ускорить запросы, сократить затраты на хранение и обеспечить соответствие требованиям законодательства.

Зачем нужен архив таблицы?

• Улучшение производительности. Уменьшение объёма активных данных ускоряет индексацию и выполнение запросов.
• Экономия места. Архивные данные часто хранятся в более дешёвых хранилищах (например, в холодных хранилищах облака).
• Соответствие нормативам. Многие отрасли требуют длительного хранения исторических данных (например, 5‑10 лет).
• Упрощение резервного копирования. Меньший объём активных данных ускоряет процесс бэкапа и восстановления.

Основные стратегии архивирования

Перемещение строк в отдельную таблицу

Самый простой способ – создать archive_<tablename> и перенести в неё «старые» записи.

Партиционирование

СУБД (PostgreSQL, MySQL, Oracle, SQL Server) поддерживают партиционирование по диапазону дат. Старые партиции могут быть «отключены» и перемещены в архив.

Вынос в отдельную базу данных

Если объём архива велик, создают отдельную базу archive_db и копируют туда таблицы.

Хранилища «Cold Storage»

Для очень редкого доступа используют облачные решения (Amazon S3 Glacier, Azure Blob Cold Tier) и сохраняют данные в виде CSV/Parquet.

Как правильно спроектировать архивную таблицу

1. Сохраняйте структуру. Архивная таблица должна иметь те же столбцы, что и оригинальная, чтобы обеспечить совместимость запросов.
2. Добавьте метаданные. Поля archived_at и archived_by позволяют отследить, когда и кем запись была архивирована.
3. Индексы. Создавайте только те индексы, которые действительно нужны для поиска в архиве (обычно по дате).
4. Разделение по датам. Если архив большой, разбейте его на партиции (по годам, кварталам).
5. Контроль доступа. Ограничьте права чтения/записи, чтобы случайно не изменить архивные данные.

Примеры реализации

Перемещение строк в PostgreSQL

-- 1. Создаём архивную таблицу
CREATE TABLE archive_orders AS
TABLE orders WITH NO DATA;

-- 2. Добавляем метаданные
ALTER TABLE archive_orders
ADD COLUMN archived_at TIMESTAMP NOT NULL DEFAULT now,
ADD COLUMN archived_by TEXT NOT NULL DEFAULT current_user;

-- 3. Переносим «старые» записи (например, старше 2 лет)
INSERT INTO archive_orders
SELECT *, now AS archived_at, current_user AS archived_by
FROM orders
WHERE order_date < now ー INTERVAL '2 years';

-- 4. Удаляем их из основной таблицы
DELETE FROM orders
WHERE order_date < now ー INTERVAL '2 years';

Партиционирование в MySQL 8.0

-- Создаём партиционированную таблицу
CREATE TABLE orders (
 id BIGINT AUTO_INCREMENT PRIMARY KEY,
 order_date DATE NOT NULL,
 customer_id BIGINT,
 total DECIMAL(10,2)
)
PARTITION BY RANGE (YEAR(order_date)) (
 PARTITION p2020 VALUES LESS THAN (2021),
 PARTITION p2021 VALUES LESS THAN (2022),
 PARTITION p2022 VALUES LESS THAN (2023),
 PARTITION p_future VALUES LESS THAN MAXVALUE
);

-- Перемещаем старую партицию в архивную схему
ALTER TABLE orders REORGANIZE PARTITION p2020 INTO (
 PARTITION p2020_archive VALUES LESS THAN (2021)
);

-- Затем экспортируем партицию в отдельную таблицу
CREATE TABLE archive.orders_2020 LIKE orders;
INSERT INTO archive.orders_2020 SELECT * FROM orders PARTITION (p2020_archive);
DROP TABLE orders PARTITION p2020_archive;

Хранение в облаке (CSV → S3)

# Экспортируем данные в CSV
COPY (
 SELECT * FROM orders
 WHERE order_date < now ー INTERVAL '3 years'
) TO '/tmp/orders_archive_2023.csv' WITH CSV HEADER;

aws s3 cp /tmp/orders_archive_2023.csv s3://my-archive-bucket/orders/2023.csv


DELETE FROM orders
WHERE order_date < now ー INTERVAL '3 years';

Лучшие практики

• Определите политику архивирования. Чётко фиксируйте, какие данные и через какой срок считаются «устаревшими».
• Автоматизируйте процесс. Используйте планировщики (cron, pgAgent, SQL Server Agent) для регулярного запуска скриптов.
• Тестируйте восстановление. Периодически проверяйте, что архивные данные можно быстро восстановить в рабочую схему.
• Мониторьте размер. Ставьте алерты, когда размер активных таблиц превышает порог.
• Документируйте. Описание всех архивных схем и процедур должно быть в Confluence/SharePoint.

Возможные подводные камни

1. Потеря целостности. При переносе записей убедитесь, что внешние ключи и ссылки сохраняются.
2. Сложные запросы. Если бизнес‑логика часто использует архивные данные, вынесение их в отдельное хранилище может замедлить отчёты.
3. Неправильные индексы. Перенос индексов в архив без необходимости только увеличивает объём хранилища.
4. Регуляторные риски. Храните архивы в соответствии с требованиями (GDPR, HIPAA и т.п.).

Инструменты и решения

Пример полной процедуры архивирования (PostgreSQL)

-- Функция, которая архивирует за один запуск
CREATE OR REPLACE FUNCTION archive_old_orders(p_years integer)
RETURNS void LANGUAGE plpgsql AS $$
DECLARE
 v_cutoff DATE := now::date ー (p_years || ' years')::interval;
BEGIN
 -- 1. Переносим в архивную таблицу
 INSERT INTO archive_orders
 SELECT *, now, current_user
 FROM orders
 WHERE order_date < v_cutoff;

 -- 2. Удаляем из основной таблицы
 DELETE FROM orders
 WHERE order_date < v_cutoff;

 RAISE NOTICE 'Archived orders older than %', v_cutoff;
END;
$$;

-- Планировщик (pgAgent) – запуск каждый месяц
-- SELECT archive_old_orders(2);

Архивирование таблиц – это не просто «удаление старых строк», а стратегический процесс, который помогает поддерживать высокую производительность базы данных, экономить ресурсы и соблюдать нормативные требования. Выбор подхода (партиционирование, отдельные архивные таблицы, холодное хранилище) зависит от объёма данных, частоты доступа и бизнес‑правил.

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

Дата публикации: 10 июля 2026 г.