Använd databasens inbyggda bulk-load-väg (Postgres COPY, MySQL ), dela filen i chunks laddade in i en med index och constraints , bygg sedan om index en gång och slå ihop — och gör hela jobbet så att en krasch kan återuppta utan att duplicera rader.
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
En naiv INSERT per rad betalar en round-trip, en parse, en WAL/redo-skrivning och en index-uppdatering 100 miljoner gånger. Vid till och med 1ms styck är det över ett dygn. Bulk-vägar vinner genom att amortisera allt detta: COPY strömmar rader i ett protokollmeddelande, batchar WAL, och hoppar över planering per sats. På verklig hårdvara gör en enda COPY 100k–500k rader/s mot några tusen för INSERT.
UNLOGGED i Postgres hoppar över WAL helt), aldrig rakt in i livetabellen. Detta isolerar laddningen från läsare och låter dig validera innan publicering.CREATE INDEX en gång — att bygga ett index i bulk (sorterat) är långt billigare än 100M inkrementella uppdateringar.COPY-strömmar. Throughput skalar med I/O och CPU tills du mättar disk eller WAL. Matcha N till kärnor/IOPS, inte "så många som möjligt".INSERT ... ON CONFLICT DO NOTHING/UPDATE (upsert) så att omkörning aldrig dubbel-insertar.Intervjuaren kontrollerar om du vet att bulk-vägen finns och varför den är storleksordningar snabbare — inte COPY-syntax. Bra: "använd COPY". Utmärkt: "COPY in i en UNLOGGED staging-tabell, index droppade, parallella chunks, bygg om efteråt, upsert för att publicera, återupptagbar via chunk-id." Den klassiska fällan är att loopa INSERTs (eller en ORM saveAll) och bli förvånad att det tar timmar; den andra fällan är att ladda direkt in i livetabellen och blockera produktion.
maintenance_work_mem/temp-utrymme; en 100M-raders index-byggnad kan spilla till disk.Ett bibliotek med IT-intervjufrågor och detaljerade svar — från Junior till Senior.
Donera