← Retour à la Base de connaissances← Question précédenteQuestion suivante →
ProgrammationDéveloppeur Backend

Comment réaliser un traitement efficace de grandes quantités de données dans SQL à l'aide d'opérations par lots (Batch Processing), et quels mécanismes de gestion de la mémoire et des transactions faut-il prendre en compte ?

Réussissez les entretiens avec l'assistant IA Hintsage

Réponse.

Le traitement de grandes quantités de données dans SQL nécessite une approche particulière pour éviter les débordements de mémoire, les blocages et garantir des performances stables. L'une des principales techniques consiste à diviser les opérations en lots : les données d'entrée sont traitées par petites portions, ce qui réduit la charge sur le serveur et permet de mieux contrôler les transactions et les annulations en cas d'erreurs.

Aspects clés :

  • Utilisation de boucles avec un paramètre de taille de lot (ROWCOUNT ou LIMIT / TOP)
  • Nombre contrôlé de lignes affectées dans une transaction
  • Après chaque lot — COMMIT, pour alléger le journal des transactions
  • En cas d'erreur — annuler uniquement le lot courant, et non l'ensemble de l'opération

Exemple (SQL Server) :

DECLARE @BatchSize INT = 1000;
WHILE 1 = 1
BEGIN
    BEGIN TRANSACTION;
    DELETE TOP(@BatchSize) FROM BigLogTable WHERE CreatedDate < '2021-01-01';
    IF @@ROWCOUNT = 0
        BREAK;
    COMMIT TRANSACTION;
END

Question piège.

Comment supprimer 100 millions d'enregistrements d'une grande table avec un impact minimal sur les performances ?

Réponse incorrecte : "Faire une grande suppression".

Réponse correcte : Supprimer par portions (par lots) avec contrôle de la taille des lots, effectuer un COMMIT après chaque bloc, réduire la charge sur le disque et les blocages si nécessaire à l'aide de pauses (WAITFOR DELAY ou équivalent).

Exemple (PostgreSQL) :

DO $$
BEGIN
  LOOP
    DELETE FROM big_table WHERE created_at < NOW() - interval '1 year' LIMIT 10000;
    EXIT WHEN NOT FOUND;
    COMMIT;
  END LOOP;
END$$;

Exemples d'erreurs réelles dues à une méconnaissance des subtilités du sujet.

Histoire

Projet : Service bancaire à forte charge. Erreur : Un développeur a lancé la suppression de journaux obsolètes avec une seule grande requête sur 80 millions de lignes. Résultat — le journal des transactions a grimpé à plusieurs téraoctets, saturant tout l'espace disque disponible, le service a "planté".

Histoire

Projet : Boutique en ligne avec un système de gestion des stocks. Erreur : Lors de l'insertion massive, la taille de la transaction n'était pas limitée. Dans le processus d'importation de grands lots, des erreurs se sont produites, l'ensemble du travail précédent a dû être annulé et répété, prenant des heures au lieu de minutes.

Histoire

Projet : Détaillant, base de données de rapports sur les commandes. Erreur : Des lots ont été utilisés, mais le COMMIT entre les itérations a été oublié — le journal des transactions a grandi de manière exponentielle, le serveur a commencé à "ralentir", et une nettoyage d'urgence des journaux a été nécessaire avec les outils standard.