Réponse.

Pour l'importation massive (bulk insert) de grandes quantités de données, on utilise des commandes et des utilitaires spécialisés : BULK INSERT, COPY, LOAD DATA INFILE, des outils externes comme bcp (SQL Server), psql (PostgreSQL), ainsi que des utilitaires ETL.

Points clés :

Utilisez des formats CSV/TXT sans transformations superflues.
Désactivez les déclencheurs et les index pendant l'importation, si les données ne nécessitent pas de vérification - cela augmente la vitesse.
Effectuez des vérifications et la validation de l'intégrité référentielle AVANT et/ou APRÈS l'importation.
Importez dans une table temporaire, validez, puis effectuez un bulk insert dans la table principale.
Essayez de diviser les données en lots, si cela est pris en charge.
Vérifiez les codes de retour / journaux - le bulk insert peut permettre de passer des échecs.

Exemple pour PostgreSQL :

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

-- Vérification des données, transfert dans la table de production après validation
INSERT INTO prod_table (id, name, age)
SELECT id, name, age FROM staging_table WHERE age >= 0 AND name IS NOT NULL;

Question piège.

Question : Pourquoi, après un bulk insert dans une grande table avec un index, peut-on observer une chute brusque de la performance des opérations suivantes ?

Réponse : Parce que le bulk insert remplit la table directement, tandis que les index ne sont recréés/mis à jour qu'après l'importation principale, ce qui peut bloquer la table et consommer des ressources. Il est recommandé de désactiver les index secondaires pendant l'importation et de les recréer après, ou de les diviser en lots.

Histoire

Dans un projet logistique, des millions de lignes ont été chargées via BULK INSERT sans table temporaire - des données invalides "bouchaient" les index avec des informations non valides, après quoi, en raison des contraintes FK et des vérifications, il n'a pas été possible de simplement "annuler" une partie des mauvaises lignes. Les données ont dû être nettoyées manuellement.

Histoire

Dans un service d'entreprise, le bulk insert a multiplié par 10 le temps d'importation, car les index secondaires n'avaient pas été désactivés pendant le chargement, et leur structure était recalculée à chaque étape.

Histoire

Dans un produit fintech, lors du chargement de grands fichiers, le bulk insert a permis de ne pas charger toutes les lignes en raison d'erreurs silencieuses, car les codes d'erreur n'avaient pas été traités correctement - une partie d'informations importantes a été perdue, et cela n'a été découvert qu'après une vérification avec des sources externes plusieurs jours plus tard.