TRUNCATE 的性能优势

TRUNCATE 语句不等同于 DROP TABLE。在 TRUNCATE 成功地执行之后，指定的 table 及其所有列和索引仍注册在数据库中，但没有数据行。在一定的时间间隔之后要求替换表中所有记录的信息管理应用中，TRUNCATE 比同等的 DROP TABLE、CREATE TABLE，以及要定义任何同义词、视图、约束、触发器、权限、分片方案和其他属性以及表的相关联的数据库对象，需要对系统目录的较少更新。

在不需要表的现有行的上下文中，与使用不带有 WHERE 子句的 DELETE 语句来清空表相比，TRUNCATE 语句通常更有效率，因为 TRUNCATE 比 DELETE 需要更少的资源和更低的日志记录开销：

DELETE FROM table 删除每一行作为分别的日志记录操作。如果在表上存在索引，则当删除行时，必须更新每一索引，且此更新还为每一行做日志记录。如果在表上定义一启用的 Delete 触发器，则还执行它的触发的活动并记录日志。
TRUNCATE table 执行对表上所有行和每一索引的 B 树结构的移除，作为单个操作，并当提交或回滚包括 TRUNCATE 的事务时，在逻辑日志中写单个条目。忽略任何启用的触发器的被触发的活动。

当表有带有下列属性的一个或多个列时，TRUNCATE 胜于 DELETE 的这些性能优势会降低：

存储在 blobspace 中的任何简单大对象数据类型
存储在sbspace 中的任何 BLOB、CLOB、复杂的或用户定义的类型
为其定义 destroy 支持函数的任何 opaque 类型。

这些特性的每一个都需要数据库服务器读取表的每一行，大幅降低 TRUNCATE 的速度。

如果表包括一个或多个您已为其注册了 am_truncate( ) 目的函数的 UDT，则 TRUNCATE 与 DELETE 之间的性能差异会在为 TRUNCATE 调用 am_truncate 接口一次与为每一行调用 destroy( ) 支持函数的相对成本上反映出来。

像在下一部分中罗列的那样，某些条件导致 TRUNCATE 失败并报错。这些条件中的某些在 DELETE 操作上没有影响，因此在那些情况下，您以 DELETE 语句移除所有行会更有效，如在 customer 表上的下列操作所示：

DELETE customer;

仅当设置 DELIMIDENT 环境变量时，才可省略紧跟在 DELETE 之后的 FROM 关键字，如在此示例中那样。