Update en SQL : guide pratique pour mettre à jour vos données

Syntaxe SQL UPDATE : SET, WHERE et ordre des clauses pour éviter les mises à jour massives

La forme de base est : UPDATE nom_table SET colonne1=valeur1, colonne2=valeur2 WHERE condition. SET décrit ce qui change. WHERE limite les lignes ciblées. Sans WHERE, vous mettez à jour toutes les lignes.

Commencez par une requête SELECT équivalente : même condition, mêmes colonnes (ou presque). Vous validez le périmètre avant de lancer l’UPDATE.

Le piège classique : oublier WHERE. En production, ça donne vite une modification globale (parfois silencieuse), puis une correction longue parce que les données ont déjà été propagées.

Une WHERE bien indexée réduit le temps d’exécution : moins de scans, moins de verrous, moins d’attente pour les autres transactions. (Oui, ça se ressent tout de suite.)

SELECT *
FROM clients
WHERE id = 123;

UPDATE clients
SET statut = 'ACTIF'
WHERE id = 123;

Mise à jour conditionnelle avancée : opérateurs, NULL, plages et logique de filtrage

Pour une mise à jour conditionnelle, combinez WHERE avec des opérateurs (>, <, BETWEEN, IN), de la logique (AND/OR) et la gestion de NULL. Attention : en SQL, NULL ne se teste pas avec “= NULL”. Utilisez IS NULL ou IS NOT NULL.

Quand les règles deviennent “métier”, gardez une condition lisible. BETWEEN pour une plage, IN pour une liste de statuts, comparaisons simples pour éviter des expressions trop longues. Exemple : cibler une période de commandes.

UPDATE commandes
SET statut = 'ANNULEE'
WHERE date_commande BETWEEN '2025-01-01' AND '2025-12-31'
  AND statut = 'EN_ATTENTE';

Le cas NULL fait trébucher même des équipes expérimentées. Pour cibler des comptes incomplets : WHERE email IS NULL. L’erreur fréquente est “email = NULL” : ça ne matche rien, donc l’update ne touche pas les lignes attendues.

UPDATE comptes
SET score = 0
WHERE email IS NULL;

Quand vous mélangez AND et OR, mettez des parenthèses. Le filtrage devient testable, et vous évitez les surprises de priorité. C’est souvent là que se joue la qualité (et le temps gagné en revue).

Mettre à jour avec une jointure : UPDATE…JOIN selon MySQL, PostgreSQL ou SQL Server

Quand la valeur à écrire dépend d’une autre table, vous pouvez mettre à jour via une jointure. La syntaxe change selon le SGBD : MySQL utilise souvent UPDATE t1 JOIN t2 ON … SET …, PostgreSQL préfère UPDATE … SET … FROM … et SQL Server emploie UPDATE avec FROM.

Le workflow fiable : choisissez la syntaxe de votre SGBD, puis contrôlez la relation avant d’écrire. Exemple : calculer un prix_final à partir d’une table de remises, puis l’appliquer à la table cible.

-- Exemple MySQL (schéma simplifié)
UPDATE ventes v
JOIN remises r ON r.id_remise = v.id_remise
SET v.prix_final = v.prix_brut * (1 - r.taux);

-- Exemple PostgreSQL (schéma simplifié)
UPDATE ventes v
SET prix_final = v.prix_brut * (1 - r.taux)
FROM remises r
WHERE r.id_remise = v.id_remise;

Risque courant : une jointure non unique. Si la table de remises contient plusieurs lignes qui correspondent à la même vente, vous pouvez écraser des valeurs de façon incohérente. Avant l’UPDATE, comptez les correspondances avec un SELECT et limitez le périmètre avec des conditions sur les deux tables.

SELECT v.id, COUNT(*) AS nb_correspondances
FROM ventes v
JOIN remises r ON r.id_remise = v.id_remise
GROUP BY v.id
HAVING COUNT(*) > 1;

Une jointure bien maîtrisée ressemble à un contrat entre tables : moins de surprises, donc moins d’allers-retours après coup. (Et franchement, c’est ce qu’on veut.)

Sécurité et fiabilité : transactions, sauvegardes, mode de test et stratégie de rollback

Pour un update sensible, exécutez-le dans une transaction : BEGIN, UPDATE, puis COMMIT seulement après validation. En cas d’erreur, ROLLBACK annule les modifications.

Réduisez le risque : commencez par une version “test” (par exemple un sous-ensemble via WHERE ; certains SGBD acceptent LIMIT). Puis vérifiez le résultat avec un SELECT de contrôle.

La transaction joue le rôle de filet. Vous lancez l’UPDATE, vous vérifiez au moins un indicateur (lignes affectées, cohérence de quelques champs), puis vous validez. Sans COMMIT, un ROLLBACK vous remet dans l’état précédent.

BEGIN;

UPDATE comptes
SET statut = 'VERIFIE'
WHERE statut = 'EN_ATTENTE'
  AND created_at < '2026-01-01';

-- Contrôle rapide
SELECT COUNT(*) AS nb_verifies
FROM comptes
WHERE statut = 'VERIFIE'
  AND created_at < '2026-01-01';

COMMIT;
-- ou ROLLBACK si le contrôle déçoit

Approche pragmatique : test sur un périmètre réduit, extension après validation. Après l’UPDATE, vérifiez le nombre de lignes affectées (selon le SGBD, c’est souvent renvoyé par l’exécution). En production, les changements critiques suivent un vrai processus de validation, pas juste “ça a l’air bon”.

Performances : indexes, cardinalité, et éviter les UPDATE lents sur grandes tables

Un UPDATE peut devenir très lent si la clause WHERE n’exploite pas d’index, ou si la jointure produit trop de lignes. Ciblez des colonnes indexées, évitez les fonctions sur la colonne filtrée (quand c’est possible), et surveillez la cardinalité de la jointure. Pour les gros volumes, faites des mises à jour par lots.

Repère rapide : sur une grande table, un UPDATE sans index sur la colonne de filtrage déclenche souvent un scan coûteux. Résultat : verrous plus longs, temps de réponse dégradé pour les autres requêtes, parfois des timeouts côté application.

Pour les jointures, la cardinalité compte. Une relation “1 vers N” non maîtrisée peut multiplier les correspondances et donc le volume de travail. Avant d’écrire, vérifiez que la jointure reste stable ; sinon, ajoutez des conditions ou corrigez la structure.

Sur des systèmes très chargés, les verrous impactent d’autres transactions. Les lots réduisent la durée des verrous : traiter par tranches (par ID ou par date). Oui, c’est un peu plus de code. Mais c’est souvent le prix pour garder un système exploitable.

-- Schéma de mise à jour par lots (conceptuel)
-- Étape 1 : choisir un sous-ensemble
-- Étape 2 : UPDATE sur ce sous-ensemble
-- Étape 3 : recommencer jusqu’à épuisement

Pièges classiques et check-list : erreurs de syntaxe, valeurs incorrectes et contrôles avant exécution

Les incidents viennent souvent de : l’absence de WHERE, une condition mal écrite, une confusion sur NULL, ou une jointure qui écrase des données. Avant d’exécuter, lancez un SELECT équivalent, vérifiez le nombre de lignes attendues, et testez sur un échantillon. En cas de doute, verrouillez la stratégie (transaction + rollback).

Check-list rapide : suivez-la et vous évitez la majorité des problèmes liés aux updates en SQL. C’est volontairement “mécanique” : ça réduit le risque et ça fait gagner du temps.

• Vérifiez le périmètre : SELECT équivalent, puis comparez le COUNT attendu.
• Confirmez la condition : parenthèses pour AND/OR, opérateurs cohérents (BETWEEN, IN, >, <).
• Gérez NULL avec IS NULL / IS NOT NULL, jamais avec “= NULL”.
• Contrôlez les types : dates au format compatible (souvent ISO), numériques sans guillemets si votre SGBD l’exige.
• Pour une jointure : vérifiez l’unicité (ou au minimum le nombre de correspondances) avant l’UPDATE.
• Envisagez une transaction : test sur sous-ensemble, puis COMMIT après validation.

Contrôle concret : si votre SELECT cible 120 lignes, votre UPDATE doit en affecter 120 (ou un nombre que vous attendez précisément). Si ce n’est pas le cas, stop. Vous cherchez la divergence avant de “continuer quand même”.

Pour les dates, utilisez des formats compatibles avec votre SGBD. Beaucoup de bases acceptent l’ISO (par exemple YYYY-MM-DD) de façon fiable. C’est un détail, mais c’est aussi là que se glissent les erreurs “discrètes”.

L’essentiel à retenir

• Toujours combiner SET avec une clause WHERE pour éviter les mises à jour globales accidentelles.
• Testez d’abord avec un SELECT équivalent pour valider le périmètre avant d’exécuter l’UPDATE.
• Gérez NULL avec IS NULL / IS NOT NULL, jamais avec “= NULL”.
• Pour les jointures, utilisez la syntaxe spécifique à votre SGBD (MySQL, PostgreSQL, SQL Server).
• Sécurisez les changements critiques via une transaction et un rollback possible.
• Optimisez les performances avec des index sur les colonnes filtrées et des mises à jour par lots si besoin.
• Faites une check-list : types, conditions, cardinalité de jointure, nombre de lignes attendues.

Références utiles

• Documentation MySQL : instruction UPDATE
• Documentation PostgreSQL : UPDATE
• Documentation Microsoft SQL Server : UPDATE (Transact-SQL)
• Transaction (base de données) : notion de rollback