Réponse.

Une mise à jour massive est une procédure critique lors de la modification d'un grand nombre de lignes dans des tables liées. Dans l'histoire de SQL, l'implémentation typique est de faire une UPDATE avec une sous-requête ou un JOIN. Problème : toute opération de mise à jour massive sans contrôle de l'ordre d'exécution bloque de nombreuses lignes, provoque une escalade des verrous et peut entraîner des blocages lors de mises à jour multiples.

Solution :

Divisez toujours la mise à jour en petits lots (par exemple, par clé primaire ou par plages de dates).
Utilisez des approches orientées SET via JOIN, mais évitez la mise à jour massive sans restrictions.
Appliquez intelligemment des filtres, indexez les champs selon les conditions WHERE, et tenez compte de l'ordre des opérations pour les tables liées.

Exemple de code (PostgreSQL) :

UPDATE Orders o
SET status = 'archived'
FROM Customers c
WHERE o.customer_id = c.id
  AND c.closed = TRUE
  AND o.status != 'archived';

Ou en paquet :

WITH upd AS (
   SELECT o.id
   FROM Orders o
   JOIN Customers c ON o.customer_id = c.id
   WHERE c.closed = TRUE
   AND o.status != 'archived'
   LIMIT 10000
)
UPDATE Orders
SET status = 'archived'
WHERE id IN (SELECT id FROM upd);

Caractéristiques clés :

Évitez de mettre à jour "toute la table à la fois" — toujours en lots.
Utilisez des index sur le champ mis à jour et le champ de filtrage.
Définissez clairement les conditions de sélection pour éviter la mise à jour massive de lignes inutiles.

Questions piégeuses.

Que se passera-t-il si vous lancez simultanément des UPDATE de tables similaires sans séparer les plages ou appliquer des filtres inverses ?

Il est probable qu'un blocage se produise : les processus bloquent les mêmes lignes en attendant l'autre. Pour l'éviter — les paquets ne doivent pas se chevaucher ou être exécutés strictement de manière séquentielle.

Y a-t-il une différence entre UPDATE via JOIN et sous-requête, en cas de changement massif de statut ?

S'il y a des index appropriés, la principale différence réside uniquement dans la lisibilité et parfois dans la performance de SGBD spécifique. Le JOIN est généralement plus rapide, car il permet à l'optimiseur de créer un meilleur plan.

Quand est-il pertinent d'utiliser TRUNCATE/DELETE au lieu de UPDATE ?

Si la logique métier le permet — par exemple, si vous devez supprimer physiquement des enregistrements archivés ou réinitialiser une table, plutôt que de simplement changer le drapeau de statut. Mais pour une mise à jour massive de statut — seul UPDATE.

Erreurs typiques et anti-modèles

Mise à jour massive "sans filtre" : verrous, rollback, blocage.
Absence d'index — balayage complet des tables.
Lancement parallèle d'UPDATE sans division des plages par clés.

Exemple de la vie réelle

Cas négatif

Dans un grand site de commerce électronique, plusieurs UPDATE ont été lancés pour changer le statut des commandes et des clients simultanément, sans division par interv'lam. Résultat : blocages mutuels, plusieurs fois un rollback forcé a été nécessaire et des données non enregistrées ont été annulées.

Avantages :

Tout dans une seule requête.

Inconvénients :

Possibilité de blocage, perte de performance, des énormes ensembles de données sont annulés même pour une petite erreur.

Cas positif

De grands ensembles ont été divisés en lots, exécutés strictement dans l'ordre, et seules les lignes nécessaires ont été traitées selon le filtre.