SQL Server误区30日谈 第19天 Truncate表的操作不会被记录到日志

复制代码 代码如下:

CREATE DATABASE TruncateTest;
GO
USE TruncateTest;
GO
ALTER DATABASE TruncateTest SET RECOVERY SIMPLE;
GO
CREATE TABLE t1 (c1 INT IDENTITY, c2 CHAR (8000) DEFAULT 'a');
CREATE CLUSTERED INDEX t1c1 on t1 (c1);
GO

SET NOCOUNT ON;
GO

INSERT INTO t1 DEFAULT VALUES;
GO 1280

CHECKPOINT;
GO

复制代码 代码如下:

SELECT COUNT (*) FROM fn_dblog (NULL, NULL);
GO

复制代码 代码如下:

TRUNCATE TABLE t1;
GO

SELECT COUNT (*) FROM fn_dblog (NULL, NULL);
GO

复制代码 代码如下:

SELECT
[Current LSN], [Operation], [Context],
[Transaction ID], [AllocUnitName], [Transaction Name]
FROM fn_dblog (NULL, NULL);

通过日志可以看出第一条显式开始Truncate Table事务，最后一条开始DeferredAlloc。正如你所见，Truncate操作仅仅是释放了构成表的页和区。

下面这个代码可以查看日志具体所做操作的描述:

复制代码 代码如下:

SELECT
[Current LSN], [Operation], [Lock Information], [Description]
FROM fn_dblog (NULL, NULL);
GO

你可以看出为了快速恢复的目的而加的相关锁（你可以在我的博文:Lock logging and fast recovery中了解更多）。

由上面日志看出，这个操作会对8个页加相关的锁，然后整个区一次性释放。释放过后会对相关的区加IX锁,也就是不能再被使用,当事务提交后才会进行deferred-drop,因此也就保证了Truncate table操作可以回滚。

另外，如果表上存在非聚集索引.那么操作方式也是类似，都是交给一个后台线程然后释放表和索引的页。释放的最小单位就是每个分配单元。按照上面步骤你自己尝试一下就应该能明白我的意思了。

PS：还有一个关于Truncate Table操作不能回滚的误区,我在:Search Engine Q&A #10: When are pages from a truncated table reused?这篇文章中进行了详细的解释。