Réponse.

Historique de la question :

La mise à jour en masse des données est requise lors de transferts, de migrations, de corrections de la logique métier. Un exemple typique : il faut changer le statut de dizaines de millions de lignes dans une table de production, sans arrêter le service, tout en maintenant la disponibilité et les performances.

Problème :

Une mise à jour normale sans condition prend beaucoup de temps, peut entraîner une escalation des verrous, bloque la table et provoque un rollback collectif en cas d'erreur. Un approche est nécessaire pour minimiser l'impact sur les utilisateurs et garantir la transactionnalité.

Solution :

Diviser l'opération en lots à l'aide de WHERE et LIMIT/TOP.
Utiliser des fonctions de fenêtre, des tables temporaires, des marqueurs temporaires.
Parfois, supprimer temporairement les index, fixer des points de sauvegarde (SAVEPOINT), utiliser un niveau d'isolation plus bas.

Exemple de code :

-- Exemple de mise à jour par lots de 10 000 lignes
WHILE 1 = 1
BEGIN
  UPDATE TOP (10000) mytable
  SET status = 'archived', updated = GETDATE()
  WHERE status = 'active';
  IF @@ROWCOUNT = 0 BREAK;
END

Caractéristiques clés :

Le traitement par lots réduit la durée de maintien des verrous
L'atomicité est garantie uniquement dans chaque minitransaction
Certaines SGBD ont des opérateurs de bulk spéciaux qui accélèrent le travail sur de grands volumes

Questions pièges.

Peut-on effectuer une mise à jour en masse en une seule transaction sans bloquer la table ?

En général, non. Une grande transaction bloque la table/des pages et augmente le risque de blocages et de time-outs. Il est préférable de travailler par lots.

L'existence d'index influence-t-elle la vitesse de mise à jour en masse ?

Oui. Toute mise à jour des champs indexés nécessite une reconstruction de l'index pour chaque ligne. Parfois, il est judicieux de retirer temporairement les index, mais cela nécessite une analyse approfondie.

Toutes les lignes sont-elles mises à jour de manière atomique lors des mises à jour par lots ?

Non, l'atomicité est garantie uniquement au sein d'un seul lot (limite de lignes/transaction). Si un lot est interrompu, certaines lignes seront mises à jour et d'autres ne le seront pas. Pour une véritable atomicité, il faut utiliser une mise à jour complète dans une seule transaction, ce qui est risqué pour de grands volumes.

Erreurs typiques et anti-patrons

Mise à jour instantanée sans limite, provoquant une escalation des verrous
Non-considération des index - attente de hautes performances sur les colonnes indexées
Non-utilisation de points de sauvegarde (SAVEPOINT)

Exemple de la vie réelle

Cas négatif

Un ingénieur technique a décidé de mettre à jour 10 millions de lignes en une seule requête dans une base de données de production : UPDATE mytable SET status = 'archived'. Le site "s'est gelé", le rollback a pris des dizaines de minutes, la performance a souffert.

Avantages :

Simplicité de la commande, minimum de code Inconvénients :
Gel/bloquage du service de production
Possible rollback important de la transaction en cas d'erreur

Cas positif

La requête est divisée en lots de 10 000 lignes avec de courtes transactions, la mise à jour se fait pendant les heures de travail sans temps d'arrêt.