sql-server – 为什么同时行使TRUNCATE和DROP？

在我事变的体系中,有很多存储进程和SQL剧本行使姑且表.行使这些表后,最好放弃它们.

我的很多同事(险些全部同事都比我更有履历)凡是会这样做：

TRUNCATE TABLE #mytemp
DROP TABLE #mytemp

我凡是在剧本中行使单个DROP TABLE.

在DROP之前当即举办TRUNCATE有什么好的来由吗？

办理要领

TRUNCATE和DROP在举动和速率上险些沟通,因此在DROP之前执行TRUNCATE是不须要的.

留意：我从SQL Server的角度编写了这个谜底,并假设它同样合用于Sybase.看来this is not entirely the case.

留意：当我第一次宣布这个谜底时,尚有其他一些评价很高的谜底 – 包罗其时接管的谜底 – 这些谜底发生了一些错误的声明：TRUNCATE未被记录; TRUNCATE无法回滚; TRUNCATE比DROP快;等等

既然已经整理了这个线程,那么后头的辩驳好像与原始题目相干.我把它们留在这里作为其他想要戳穿这些神话的人的参考.

有一些风行的谎话 – 纵然在履历富厚的DBA中也很广泛 – 也许会引发这种TRUNCATE-then-DROP模式.他们是：

>神话：未记录TRUNCATE,因此无法回滚.
>神话：TRUNCATE比DROP快.

让我辩裁魅这些谎话.我从SQL Server的角度来看这个辩驳,但我在这里说的统统应该同样合用于Sybase.

记录TRUNCATE,可以回滚.

> TRUNCATE是一个记录操纵,因此it can be rolled back.只需将其包装在一个事宜中.

USE [tempdb];
SET NOCOUNT ON;

CREATE TABLE truncate_demo (
    whatever    VARCHAR(10)
);

INSERT INTO truncate_demo (whatever)
VALUES ('log this');

BEGIN TRANSACTION;
    TRUNCATE TABLE truncate_demo;
ROLLBACK TRANSACTION;

SELECT *
FROM truncate_demo;

DROP TABLE truncate_demo;

但请留意,这是Oracle的not true.固然Oracle的除掉和重做成果记录并受其掩护,但用户无法回滚TRUNCATE和其他DDL语句,由于Oracle会在全部DDL语句之前和之后当即发出implicit commits.
> TRUNCATE记录起码,而不是完全记录.那是什么意思？假设你TRUNCATE一个表. TRUNCATE不是将每个已删除的行放在事宜日记中,而只是将它们地址的数据页标志为未分派.这就是为什么它云云之快.这也是您无法行使日记阅读器从事宜日记中规复TRUNCATE-ed表的行的缘故起因.全部你会发明有对已扫除分派的数据页面的引用.

将此与DELETE举办较量.假如删除表中的全部行并提交事宜,理论上您如故可以在事宜日记中找到已删除的行并从哪里规复它们.这是由于DELETE将每个已删除的行写入事宜日记.对付大型表,这将使它比TRUNCATE慢得多.

DROP和TRUNCATE一样快.

>与TRUNCATE相同,DROP是一种最低限度记录的操纵.这意味着DROP也可以回滚.这也意味着it works exactly the same way为TRUNCATE. DROP不会删除单个行,而是将响应的数据页标志为未分派,并其它将表的元数据标志为已删除.
>由于TRUNCATE和DROP的事变方法完全沟通,以是它们的运行速率与其他方法一样快.在DROP-ing之前没有须要对一个表举办TRUNCATE.假如您不信托我,请在您的开拓实例上运行this demo script.

在我的当地呆板上有一个热缓存,我获得的功效如下：

table row count: 134,217,728

run#        transaction duration (ms)
      TRUNCATE   TRUNCATE then DROP   DROP
==========================================
01       0               1             4
02       0              39             1
03       0               1             1
04       0               2             1
05       0               1             1
06       0              25             1
07       0               1             1
08       0               1             1
09       0               1             1
10       0              12             1
------------------------------------------
avg      0              8.4           1.3

因此,对付一个1.34亿行表,DROP和TRUNCATE现实上都没偶然刻. (在冷缓存中,第一次运行或两次运行约莫必要2-3秒.)我还以为TRUNCATE然后DROP操纵的均匀一连时刻较长可归因于我当地计较机上的负载变革而不是由于组合是某种方法神奇地比个体动作差一个数目级.事实,它们险些完全沟通.

假如您对这些操纵的日记记录开销感乐趣,请参阅Martin has a straightforward explanation.

（编辑：湖南网）

【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容!