Truncate 事务陷阱(被删除的数据无法回滚)

现象

• Java代码如下，执行对某张表的全量更新。

@Transactional(propagation = Propagation.REQUIRED)
public void reloadFooData() {
	
	clearAllRecord();	// 清空所有记录
	
	rebuildAllData();	// 重新插入所有记录
}
1
2
3
4
5
6
7

加了事务注解，reloadFooData()方法中的语句要么都执行成功，要么都执行失败(回滚)。
但我的情况是：clear操作成功，rebuild失败。且没有回滚导致我的数据丢了！！！

我在clearAllRecord()方法中执行的SQL是truncate table tb_name，是为了快速清空表数据。
改为delete from tb_name即可。

原因：truncate掉的数据无法通过事务恢复

Conslusion

`truncate table tb_name`
`delete from tb_name`
1
2

同：结果都是删除了表中的所有记录。
异：
不带where条件的delete语句会记录删除每一行记录的日志。而truncate不记录每一行的，只记录页面的释放。
所以其各自的优点：
delete的记录可回滚；
truncate语句执行更快(执行过程中占用的系统和日志资源更少)。

Refs

• 微软: TRUNCATE TABLE (Transact-SQL)
  Removes all rows from a table or specified partitions of a table, without logging the individual row deletions.
  TRUNCATE TABLE is similar to the DELETE statement with no WHERE clause;
  however, TRUNCATE TABLE is faster and uses fewer system and transaction log resources.
  从一张表(的指定分区)删除所有的行，而不记录单个行的删除。
  truncate 的操作效果类似于 不带where条件的delete语句。
  区别就在于：truncate操作更快，会使用的系统和事务日志资源更少。

• Rollback TRUNCATE Command in Transaction
  This is very common concept that truncate can not be rolled back.
  I always hear conversation between developer if truncate can be rolled back or not.
  这是一个很常见的概念：truncate操作能否被回滚。我总是听到一些开发者之间会讨论这个问题。

  If you use TRANSACTIONS in your code, TRUNCATE can be rolled back.
  If there is no transaction is used and TRUNCATE operation is committed, it can not be retrieved from log file.
  TRUNCATE is DDL operation and it is not logged in log file.
  如果你在代码中使用了 TRANSACTIONS， truncate可以被回滚。
  如果没有事务被使用，并且truncatec操作已经被提交。那就不能在日志文件中查询到他。
  truncate是DDL(数据定义语言)，不会被记录到日志文件中。

  Truncate IS a logged operation, it just doesn’t log removing the records, it logs the page deallocations.
  truncate是一个有日志记录的操作，他不记录删掉的行，而只会记录页面的释放。