课程背景
这篇课程文档，相比前面几篇，可能会稍微偏底层实现原理一点儿。
大家可以根据需求，选择性地阅读感兴趣的部分。
在这篇文档中，我打算简单介绍一下 OceanBase 在 4.x 版本中，相较于 3.x 版本，对 truncate table 做的两个比较重要的优化：
- 第一个优化是 truncate table 实现方式的变更，这里会牵扯出一丁点儿 OceanBase 数据库大版本的进化史。
- 第二个优化是 DDL 变更的并行架构优化，主要也是为了能让 truncate table 操作变得更快。
本期临时改下积分抽奖的规则，通过抽奖获得的积分奖励，会从 200 积分 * 1 变成 50 积分 * 4，同时发给四个通过课后小测的幸运用户，让福利尽量更加 “雨露均沾” 一些。
边学边练，效果拔群
正所谓 “纸上得来终觉浅，实践才能出真知”，强烈推荐大家点击下面的链接，根据在线体验页面左边的实验文档，亲自体验一把并行 DDL 带来的性能提升！
-
在线实验地址：《通过并行 Truncate Table 提升大批量清空表的性能》
-
这个实验可以使用以下连接串连接数据库：
obclient -h127.0.0.1 -uroot@sys -P2881 -Dtestdb -A说明：
因为是实验环境，所以可以偷懒使用 sys 租户。
但生产环境中尽量不要在 sys 租户里直接创建数据库对象，尽量在用户租户里进行相关操作。
-
在进行实验的过程中，建议大家尝试通过 oceanbase.__all_ddl_operation 系统表，自行探索和分析一下 truncate table 这个 DDL，在 4.x 中实现方式和 3.x 中实现方式的不同点。
-
下图是在 ODC 中，用 3.x 版本执行 truncate table，并查看系统表记录的 DDL 执行序列：
-
在上图中，大家可能会发现一个有趣的地方，就是在 OceanBase 3.x 及更早的版本中，我只执行了一条 truncate table，但系统记录的 DDL 中却有两条 truncate table，而且 table id 好像还在执行 truncate table 的过程中，发生了变化？
是不是感觉 operation_type = 24 的这行数据，像记录的是把 t1 表给 drop 的动作，然后 operation_type = 23 的这行数据，像记录的是重新创建了一个新 t1 表的动作？（Operation Type 是个枚举值，详见：ob_schema_service.h）
大家可以到在线体验的 4.x 环境中，也执行一下这个同样的 SQL 序列，拿结果和上面那张截图对比下，看看能获得什么样的发现？
# 数据库的连接串
obclient -h127.0.0.1 -uroot@sys -P2881 -Dtestdb -A
create table t1(c1 int);
TRUNCATE table t1;
select table_id, operation_type, ddl_stmt_str
from oceanbase.__all_ddl_operation
where table_id > 500000
and ddl_stmt_str != '';
小提示：
大家如果都不来做实验的话，老板以后就不会再让兹拉坦更新这些教程文档了。大家的对在线实验的支持，是兹拉坦的老板让兹拉坦更新这些教程内容的动力！
需要先登录 OceanBase 账号，才能初始化屏幕右边的实验环境进行实验。
在实验环境里，干什么都可以。大家不要受限于屏幕左边的实验手册，可以天马行空地做一些你感兴趣的事情，或者验证一些你对 OceanBase 官网文档的疑问、以及自己的猜想等等（甚至可以尝试怎么搞能把这个实验环境里的 OBServer 给弄崩）。
欢迎大家平时在学习 OceanBase 的过程中，也都能充分利用在线体验页面为您提供的一些实验环境，来体验 OceanBase 中您感兴趣的新特性。
-
课后小测地址：【DBA 实战营】并行 DDL 课后小测
- 大家完成课后小测，并在小测中上传实验截图，就可以自动从社区论坛中获取 10 积分，并自动获得抽奖资格，有机会获得实体礼物或积分奖励。
2025.07.30 更新
今天教程交流群里有老师提问说：“truncate partition，是否也是 drop 掉分区，然后再 add 回来呢？”
drop partition 不需要像删表那样去处理表上的那些附属对象，所以个人理解 truncate partition 无论是实现成 drop partition + create partition，还是实现成只替换分区对应的 tablet id，不改 partition id，影响都不大。
欢迎大家在实验环境里也自行设计一个实验，验证一下这个猜想是否是正确的。
附上一个简单的 SQL 执行序列（需要自行替换其中的 table id）：
CREATE TABLE t_log_part_by_range (
log_id bigint NOT NULL
, log_value varchar(50)
, log_date timestamp NOT NULL
) PARTITION BY RANGE(UNIX_TIMESTAMP(log_date))
(
PARTITION M202001 VALUES LESS THAN(UNIX_TIMESTAMP('2020/02/01'))
, PARTITION M202002 VALUES LESS THAN(UNIX_TIMESTAMP('2020/03/01'))
, PARTITION M202003 VALUES LESS THAN(UNIX_TIMESTAMP('2020/04/01'))
, PARTITION M202004 VALUES LESS THAN(UNIX_TIMESTAMP('2020/05/01'))
, PARTITION M202005 VALUES LESS THAN(UNIX_TIMESTAMP('2020/06/01'))
);
select table_id from oceanbase.__all_table
where table_name = 't_log_part_by_range';
select table_id, part_id, part_name, is_deleted, gmt_modified
from oceanbase.__all_part_history
where table_id = xxxx order by gmt_modified;
ALTER TABLE t_log_part_by_range TRUNCATE PARTITION M202001, M202002;
select table_id, part_id, part_name, is_deleted, gmt_modified
from oceanbase.__all_part_history
where table_id = xxxx
order by gmt_modified;
如果被 truncate 的 partition 的 part_id 发生了变化，说明就是 drop + create。大家不妨也直接通过实验来验证下这位老师的猜想是否是正确的~
来晚了