Thursday, March 28, 2013

Delete Vs Truncate Table

I have read this comparision many times sometime in very much deeply. But after sometime I usualy forget some of the points (short term memory lost :) ).

Very simple point is that TRUNCATE TABLE is similar to DELETE with no WHERE clause however, TRUNCATE TABLE is faster and uses fewer system and transaction log resource.


  • No WHERE clause
         Truncate is fast as it doesn't have where clause the it works for complte table
  • Less transaction log space is used.
    The DELETE statement removes rows one at a time and records an entry in the transaction log for each deleted row. TRUNCATE TABLE removes the data by deallocating the data pages used to store the table data and records only the page deallocations in the transaction log.
  • Fewer locks are typically used.
    When the DELETE statement is executed using a row lock, each row in the table is locked for deletion. TRUNCATE TABLE always locks the table and page but not each row.
  • Without exception, zero pages are left in the table.
    After a DELETE statement is executed, the table can still contain empty pages. For example, empty pages in a heap cannot be deallocated without at least an exclusive (LCK_M_X) table lock. If the delete operation does not use a table lock, the table (heap) will contain many empty pages. For indexes, the delete operation can leave empty pages behind, although these pages will be deallocated quickly by a background cleanup process.
    If the table contains an identity column, the counter for that column is reset to the seed value defined for the column. If no seed was defined, the default value 1 is used. To retain the identity counter, use DELETE instead.


    You cannot use TRUNCATE TABLE on tables that:
    • Are referenced by a FOREIGN KEY constraint. (You can truncate a table that has a foreign key that references itself.)
    • Participate in an indexed view.
    • Are published by using transactional replication or merge replication.

No comments: