SQL Pratique
TRUNCATE, DELETE et DROP SQL : quelles différences ?
8 min de lecture

TRUNCATE, DELETE et DROP SQL : quelles différences ?

TRUNCATE, DELETE ou DROP : comprenez les différences en SQL, choisissez la bonne commande et évitez les erreurs irrécupérables en production.

Avatar de Thomas LeroyThomas Leroy

Supprimer des données en SQL, ça semble simple — jusqu'au jour où vous exécutez la mauvaise commande en production. TRUNCATE, DELETE et DROP sont trois commandes SQL de suppression, mais elles n'ont ni le même périmètre, ni le même comportement transactionnel, ni les mêmes conséquences. Confondre les deux premières vous coûtera du temps ; confondre la troisième avec les autres peut vous coûter votre base entière.

Cet article clarifie chaque commande, explique quand l'utiliser, et vous donne les réflexes pour ne plus hésiter — en entretien comme en situation réelle.

📌 Ce qu'il faut retenir

  • DELETE supprime des lignes sélectivement, peut être annulé avec ROLLBACK, et déclenche les triggers
  • TRUNCATE vide une table entière, est souvent non-transactionnel selon le SGBD, et est bien plus rapide
  • DROP supprime la table elle-même (structure + données), une action définitive dans la plupart des cas
  • Le choix entre les 3 dépend du besoin : filtrage, réinitialisation ou destruction complète de l'objet

DELETE : la suppression chirurgicale ligne par ligne

DELETE est la commande la plus flexible des trois. Elle supprime les lignes d'une table selon une condition définie dans une clause WHERE. Sans WHERE, elle supprime toutes les lignes — mais en les traitant une par une.

-- Supprimer les commandes annulées depuis plus de 6 mois
DELETE FROM commandes
WHERE statut = 'annulé'
  AND date_creation < CURRENT_DATE - INTERVAL '6 months';

Chaque suppression est journalisée dans le log des transactions. Cela signifie qu'un ROLLBACK peut annuler l'opération tant que la transaction n'est pas commitée. C'est la raison pour laquelle DELETE est plus lent sur de grands volumes : le moteur SQL écrit chaque suppression dans le journal.

DELETE déclenche également les triggers BEFORE DELETE et AFTER DELETE définis sur la table. Si votre architecture repose sur des triggers d'audit, cette commande les respecte. Pour approfondir ce sujet, consultez notre guide sur les triggers SQL.

DELETE avec JOIN : des suppressions conditionnées par d'autres tables

Il est possible de combiner DELETE avec une jointure pour supprimer des lignes en fonction d'une table liée. Cette syntaxe varie selon le SGBD — MySQL, PostgreSQL et SQL Server ont chacun leur approche. Nous l'avons détaillée dans l'article dédié au DELETE avec JOIN.

TRUNCATE : vider une table à grande vitesse

TRUNCATE TABLE supprime toutes les lignes d'une table en une seule opération, sans passer ligne par ligne. Le moteur libère les pages de données directement, sans journalisation individuelle de chaque ligne.

-- Vider complètement la table de logs temporaires
TRUNCATE TABLE logs_temporaires;

Le gain de performance est significatif sur les grandes tables. Une table de 50 millions de lignes peut être vidée en quelques secondes avec TRUNCATE, là où un DELETE sans WHERE prendrait plusieurs minutes.

Ce que TRUNCATE ne fait pas

TRUNCATE ne déclenche pas les triggers de suppression dans la plupart des SGBD. PostgreSQL est une exception notable : depuis la version 8.4, il supporte les triggers AFTER TRUNCATE. En revanche, MySQL et SQL Server n'activent pas les triggers sur TRUNCATE.

Par défaut, TRUNCATE remet également à zéro les compteurs AUTO_INCREMENT (ou SERIAL en PostgreSQL), ce que DELETE ne fait pas.

⚠️ Attention

Dans PostgreSQL, TRUNCATE est transactionnel et peut être annulé avec ROLLBACK. Dans MySQL (avec InnoDB), un TRUNCATE provoque un commit implicite, ce qui rend l'annulation impossible. Vérifiez le comportement de votre SGBD avant d'exécuter cette commande en production.

TRUNCATE et les clés étrangères

TRUNCATE échoue si la table est référencée par une clé étrangère active depuis une autre table. Il faut d'abord vider les tables dépendantes, ou désactiver temporairement les contraintes. En PostgreSQL, l'option CASCADE permet de propager le vidage aux tables liées :

TRUNCATE TABLE utilisateurs CASCADE;

À utiliser avec une extrême prudence — la cascade peut vider des tables que vous n'aviez pas anticipées.

DROP : supprimer l'objet SQL lui-même

DROP TABLE ne supprime pas des lignes : il supprime la table dans son intégralité — sa structure, ses données, ses index, ses contraintes et ses triggers associés.

-- Supprimer définitivement la table de staging
DROP TABLE IF EXISTS staging_import;

La clause IF EXISTS évite une erreur si la table n'existe pas. C'est une bonne pratique dans les scripts de migration.

DROP s'applique également aux autres objets SQL : DROP VIEW, DROP INDEX, DROP DATABASE, DROP SCHEMA. Dans tous les cas, l'action est destructrice et généralement irréversible (hors backup ou corbeille spécifique à certains SGBD comme Oracle Flashback).

💡 Bon à savoir

En entretien technique, les recruteurs testent souvent votre connaissance du comportement transactionnel de ces commandes. Savoir que DELETE est toujours annulable, que TRUNCATE dépend du SGBD, et que DROP est définitif montre une vraie maturité sur la gestion des données.

Comparatif complet des 3 commandes

Critère DELETE TRUNCATE DROP
Cible Lignes sélectivement Toutes les lignes La table entière (structure + données)
Clause WHERE ✅ Oui ❌ Non ❌ Non
Transactionnel ✅ Toujours ⚠️ Selon le SGBD ❌ Généralement non
Déclenche les triggers ✅ Oui ⚠️ PostgreSQL seulement ❌ Non
Remet à zéro AUTO_INCREMENT ❌ Non ✅ Oui (selon SGBD) N/A (table supprimée)
Performance sur grand volume 🐢 Lente 🚀 Très rapide 🚀 Instantané
Récupération possible ✅ Via ROLLBACK ⚠️ PostgreSQL uniquement ❌ Backup requis
Compatible clés étrangères actives ⚠️ Si pas de dépendance ❌ Échec ou CASCADE ❌ Échec ou CASCADE

Choisir la bonne commande selon le contexte

Voici comment raisonner rapidement face à un besoin de suppression :

  • Vous voulez supprimer certaines lignes précises → utilisez DELETE avec une clause WHERE
  • Vous voulez vider complètement une table pour la réutiliser → préférez TRUNCATE, plus rapide et qui remet les compteurs à zéro
  • Vous voulez supprimer une table temporaire après un ETL ou une migration → utilisez DROP TABLE IF EXISTS
  • Vous êtes en production et l'action doit être réversible → utilisez DELETE dans une transaction explicite avec BEGIN / ROLLBACK en cas de doute

Cette logique de décision est directement applicable lors d'un test technique SQL, où ce type de question revient régulièrement pour évaluer la rigueur d'un candidat.

Toujours tester avec un SELECT avant de supprimer

Avant d'exécuter un DELETE, transformez-le mentalement en SELECT pour vérifier le périmètre :

-- Vérification avant suppression
SELECT COUNT(*) FROM commandes
WHERE statut = 'annulé'
  AND date_creation < CURRENT_DATE - INTERVAL '6 months';

-- Suppression une fois le périmètre validé
DELETE FROM commandes
WHERE statut = 'annulé'
  AND date_creation < CURRENT_DATE - INTERVAL '6 months';

Ce réflexe simple évite la majorité des accidents en production.

Les pièges classiques en entretien

Les recruteurs posent souvent des questions du type : "Quelle est la différence entre DELETE et TRUNCATE ?" ou "Que se passe-t-il si vous TRUNCATE une table référencée par une clé étrangère ?"

Les réponses attendues vont au-delà de la définition brute. Mentionner le comportement transactionnel selon le SGBD, l'impact sur les triggers, et la réinitialisation des séquences montre que vous avez pratiqué ces commandes en conditions réelles.

Un autre piège courant : confondre DROP TABLE et TRUNCATE TABLE dans un script de réinitialisation de base. TRUNCATE conserve la structure, DROP la détruit. Si votre script enchaîne sur un INSERT ou CREATE INDEX, seul TRUNCATE permet de ne pas recréer la table ensuite.

Questions fréquentes

Peut-on annuler un TRUNCATE avec un ROLLBACK ?

Cela dépend du SGBD. PostgreSQL supporte le ROLLBACK d'un TRUNCATE car il est pleinement transactionnel. MySQL avec InnoDB provoque un commit implicite avant le TRUNCATE, rendant l'annulation impossible. Vérifiez toujours le comportement de votre environnement cible.

Quelle commande est la plus rapide pour vider une grande table ?

TRUNCATE est systématiquement plus rapide que DELETE sans WHERE sur les grandes tables. Il libère les pages de données directement plutôt que de journaliser chaque suppression ligne par ligne. Sur 10 millions de lignes, la différence peut aller de quelques secondes à plusieurs minutes.

Est-ce que DROP TABLE supprime aussi les index ?

Oui, DROP TABLE supprime la table et tous les objets qui lui sont associés : index, contraintes, triggers et permissions. Aucun de ces éléments n'est conservé. Si vous souhaitez recréer la table, vous devez tout redéfinir.

Peut-on utiliser TRUNCATE avec une condition WHERE ?

Non. TRUNCATE ne supporte pas la clause WHERE. Si vous avez besoin de supprimer des lignes selon une condition, vous devez obligatoirement utiliser DELETE. TRUNCATE est une opération tout-ou-rien sur la table entière.

Que se passe-t-il avec les vues basées sur une table droppée ?

Si vous supprimez une table avec DROP TABLE, les vues qui dépendent de cette table deviennent invalides. Selon le SGBD, elles restent dans le catalogue mais génèrent une erreur à l'exécution. PostgreSQL vous avertit des dépendances ; SQL Server invalide silencieusement la vue.

Conclusion

DELETE, TRUNCATE et DROP couvrent des besoins distincts que tout praticien SQL doit maîtriser. DELETE offre la précision chirurgicale avec réversibilité totale. TRUNCATE maximise la performance pour les vidages complets. DROP détruit l'objet lui-même, à réserver aux opérations de maintenance structurelle.

Maîtriser ces nuances — notamment le comportement transactionnel selon le SGBD — vous donnera un avantage concret lors de vos entretiens techniques. Entraînez-vous directement dans l'environnement SQL de SQL Pratique pour valider vos acquis avec des exercices corrigés et un interpréteur en ligne.

Prêt à vous entraîner ?

50 exercices SQL interactifs avec éditeur en ligne, chronomètre et feedback IA.

Voir les exercices