对原始答案的一个小修正——删除也会产生大量的重做(因为undo本身是由重做保护的)。这可以从autotrace输出中看到:

SQL> delete from t1;

10918 rows deleted.

Elapsed: 00:00:00.58

Execution Plan
----------------------------------------------------------
   0      DELETE STATEMENT Optimizer=FIRST_ROWS (Cost=43 Card=1)
   1    0   DELETE OF 'T1'
   2    1     TABLE ACCESS (FULL) OF 'T1' (TABLE) (Cost=43 Card=1)




Statistics
----------------------------------------------------------
         30  recursive calls
      12118  db block gets
        213  consistent gets
        142  physical reads
    3975328  redo size
        441  bytes sent via SQL*Net to client
        537  bytes received via SQL*Net from client
          4  SQL*Net roundtrips to/from client
          2  sorts (memory)
          0  sorts (disk)
      10918  rows processed

一眨眼的功夫就不能做DDL。

“Truncate不会记录任何东西”是正确的。我想更进一步:

Truncate不会在事务的上下文中执行。

截断比删除的速度优势应该是明显的。根据你的情况，这种优势从微不足道到巨大不等。

然而，我看到截断无意中破坏了引用完整性，并违反了其他约束。通过在事务外部修改数据而获得的权力，必须与在没有安全网的情况下走钢丝时继承的责任相平衡。

这两个操作的另一个区别是，如果表包含一个标识列，则在TRUNCATE下该列的计数器将重置1(或为该列定义的种子值)。DELETE没有这种影响。

如果将TRUNCATE包装在事务中，则可以回滚。

请参阅下面的两个参考资料并自行测试:-

http://blog.sqlauthority.com/2007/12/26/sql-server-truncate-cant-be-rolled-back-using-log-files-after-transaction-session-is-closed/

http://sqlblog.com/blogs/kalen_delaney/archive/2010/10/12/tsql-tuesday-11-rolling-back-truncate-table.aspx

截断与删除是SQL面试中最臭名昭著的问题之一。一定要向面试官解释清楚，否则可能会让你丢掉这份工作。问题是没有多少人意识到这一点，所以如果你告诉他们YES Truncate可以回滚，他们很可能会认为答案是错误的。

最大的区别是truncate是不记录日志的操作，而delete是。

简单地说，这意味着在数据库崩溃的情况下，不能通过截断恢复所操作的数据，但可以通过删除恢复。

详情请点击这里