Ответ.

Для массового импорта (bulk insert) больших объёмов данных используются специализированные команды и утилиты: BULK INSERT, COPY, LOAD DATA INFILE, внешние инструменты типа bcp (SQL Server), psql (PostgreSQL), а также утилиты ETL.

Ключевые моменты:

Используйте форматы CSV/TXT без лишних преобразований.
Отключайте триггеры и индексы на время импорта, если данные не требуют проверки — это увеличивает скорость.
Используйте проверки и валидацию ссылочной целостности ДО и/или ПОСЛЕ импорта.
Импортируйте во временную таблицу, валидируйте, потом делайте массовую вставку в основную.
Постарайтесь делить данные на батчи, если это поддерживается.
Проверяйте коды возврата/логи — bulk insert может допускать пропуск сбоев.

Пример для PostgreSQL:

COPY staging_table (id, name, age)
FROM '/path/to/data.csv'
DELIMITER ','
CSV HEADER;

-- Проверка данных, перенос в боевую таблицу после валидации
INSERT INTO prod_table (id, name, age)
SELECT id, name, age FROM staging_table WHERE age >= 0 AND name IS NOT NULL;

Вопрос с подвохом.

Вопрос: Почему после bulk insert в крупную таблицу с индексом может наблюдаться резкое падение производительности последующих операций?

Ответ: Потому что bulk insert заполняет таблицу напрямую, а индексы пересоздаются/обновляются только после основного импорта, что может блокировать таблицу и съедать ресурсы. Рекомендуется отключать вторичные индексы на время импорта и пересоздавать их после окончания, либо разбивать на батчи.

История

В проекте логистики заливали миллионы строк через BULK INSERT без временной таблицы — невалидные данные "забивали" индексы невалидной информацией, после чего из-за FK и чек-констрейнтов не удалось просто "откатить" часть плохих строк. Данные пришлось чистить вручную.

История

В корпоративном сервисе bulk insert увеличивал время импорта в 10 раз, потому что во время заливки не были отключены вторичные индексы, а на каждом шаге пересчитывалась их структура.

История

В fintech продукте при загрузке больших файлов bulk insert позволил загрузить не все строки из-за silent-ошибок, так как не были правильно обработаны коды ошибок — часть важной информации потеряли, а обнаружили только после сверки с внешними источниками через несколько дней.