TRUNCATE et DELETE peuvent avoir le même effet sur une table si le DELETE n’a pas de clause WHERE.
Mais est-ce bien la même chose qui se passe au niveau des données ?

En réalité, ces deux instructions ont bien des éléments qui les différencient :

=> TRUNCATE est une instruction DDL, alors que DELETE est une instruction DML.
Conséquence directe : TRUNCATE ne peut pas avoir de clause WHERE.

=> TRUNCATE ne peut pas être exécuté :

1. sur une table disposant de contraintes d’intégrité (clé primaire référencée par au moins une table, et clés étrangères)
2. sur une table qui est répliquée
3. dans une base de données répliquée par envoi de journaux

DELETE peut l’être si les contraintes d’intégrité restent respectées.

=> TRUNCATE ne déclenche pas un trigger sur DELETE, ce qui est le cas pour DELETE.
Donc l’utilisation de TRUNCATE peut causer des problèmes de consistance des données, car si l’on a supprimé les contraintes d’intégrité pour pouvoir exécuter un TRUNCATE, le traitement du trigger sur DELETE ne sera pas exécuté non plus.

=> TRUNCATE enregistre dans le fichier du journal des transactions les pages de données désallouées, et supprime les pointeurs des index.
C’est ce qui fait que TRUNCATE est plus rapide à s’exécuter que DELETE : TRUNCATE utilise très peu de verrous par rapport à DELETE, qui nécessite dont plus de ressources disque.
En effet, DELETE enregistre dans le fichier du journal des transactions toutes les données de chaque ligne affectée par l’instruction.
En realité donc, TRUNCATE n’efface pas les données contenues dans les pages, mais marque celles-ci comme réutilisables.
DELETE en revanche supprime physiquement les données.

=> En conséquence, les données supprimées par un DELETE sont restaurables; les données « supprimées » par un TRUNCATE ne le sont pas.

=> TRUNCATE réinitialise la valeur d’une colonne de type entier avec la propriété d’auto-incrémentation (IDENTITY). DELETE laisse cette valeur inchangée.

Et bonne suppression de données

ElSüket.