Ответ

Массовая вставка данных (bulk insert) — типичная задача при миграции, импорте или пополнении больших таблиц. Эффективность такой операции зависит от нескольких факторов:

Использование пакетных вставок (Batch Insert): Разбивайте данные на разумные пакеты (batch) — обычно это тысячи строк за раз. Это снижает нагрузку на журналы транзакций и уменьшает блокировки.
Отключение индексов и ограничений на время bulk insert: Временное удаление или отключение вторичных индексов и внешних ключей может ускорить вставку. После завершения операции индексы пересоздайте.
Контроль над транзакциями: Выполняйте вставки внутри транзакций с фиксированным количеством строк, чтобы избежать накопления слишком больших журналов (log file).
Использование специальных инструментов: Например, BULK INSERT или COPY (PostgreSQL) — они работают быстрее обычных INSERT в цикле.
Загрузка только необходимых столбцов: Исключайте лишние данные — это уменьшает объем трафика и время обработки.

Пример (SQL Server):

BULK INSERT my_table
FROM 'C:\data\bulkdata.csv'
WITH (
  FIELDTERMINATOR = ',',
  ROWTERMINATOR = '
',
  BATCHSIZE = 5000,
  TABLOCK
);

TABLOCK уменьшает конфликты блокировок при массовых вставках.

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

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

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

Пример кода:

-- Неправильно:
BEGIN TRAN;
ALTER INDEX ALL ON my_table DISABLE;
-- ... bulk insert ...
ALTER INDEX ALL ON my_table REBUILD;
COMMIT;

Такое отключение недопустимо внутри длинных транзакций!

Примеры реальных ошибок из-за незнания тонкостей темы

История 1: В одном проекте параллельные bulk insert в таблицу с несколькими уникальными индексами привели к частым deadlock'ам и резкому проседанию производительности. Решением было временное отключение неключевых индексов на период импорта и уменьшение размера batch операций.

История 2: Разработчики забыли отключить контроль внешних ключей на период загрузки данных, и каждый insert проверял наличие связанных записей в других крупных таблицах. Это увеличило время загрузки с 40 минут до 9 часов. После отключения constraint'ов вставка заняла 12 минут.

История 3: Попытка вставить большой файл единым запросом (без пакетирования и без транзакций) привела к переполнению журнала транзакций (transaction log full) и аварийному завершению сервера баз данных. После перехода к batch processing проблема ушла.