Use o caminho nativo de bulk-load do banco (COPY do Postgres, do MySQL), divida o arquivo em chunks carregados em uma com índices e constraints , depois reconstrua os índices uma vez e faça merge — e torne todo o job para que um crash possa retomar sem duplicar linhas.
LOAD DATA100M-row CSV
│ split by byte offset
▼
[chunk 1] [chunk 2] ... [chunk N] N parallel workers
│ │ │
└──── COPY / LOAD DATA (no indexes) ────▶ staging_table (UNLOGGED)
│
rebuild indexes + validate
│
INSERT ... SELECT (upsert) into target
Um INSERT ingênuo por linha paga uma ida e volta, um parse, uma escrita de WAL/redo e um update de índice 100 milhões de vezes. Mesmo a 1ms cada, isso passa de um dia. Caminhos de bulk vencem amortizando tudo isso: COPY faz streaming das linhas em uma mensagem de protocolo, agrupa o WAL e pula o planning por instrução. Em hardware real um único COPY faz 100k–500k linhas/seg versus alguns milhares para INSERT.
UNLOGGED no Postgres pula o WAL por completo), nunca direto na tabela viva. Isso isola a carga dos leitores e permite validar antes de publicar.CREATE INDEX uma vez — construir um índice em bulk (ordenado) é muito mais barato que 100M de updates incrementais.COPY. O throughput escala com I/O e CPU até você saturar disco ou WAL. Ajuste N aos cores/IOPS, não "o máximo possível".INSERT ... ON CONFLICT DO NOTHING/UPDATE (upsert) para que re-rodar nunca insira em duplicidade.O entrevistador está verificando se você sabe que o caminho de bulk existe e por que é ordens de magnitude mais rápido — não a sintaxe do COPY. Bom: "usar COPY". Excelente: "COPY em uma tabela de staging UNLOGGED, índices removidos, chunks paralelos, reconstruir depois, upsert para publicar, retomável por id de chunk." A armadilha clássica é fazer loop de INSERTs (ou um saveAll de ORM) e se surpreender que leva horas; a segunda armadilha é carregar direto na tabela viva e bloquear a produção.
maintenance_work_mem/espaço temporário; uma construção de índice de 100M de linhas pode transbordar para o disco.Uma biblioteca de perguntas de entrevista de TI com respostas detalhadas — de Júnior a Sênior.
Doar