从串行到并行，OceanBase 批量清理加速破解清表瓶颈 | 最佳实践 24

在 OceanBase 的日常运维中，批量清理大量小表数据是高频且关键的场景，其效率直接影响后续业务的正常推进。不同版本的 OceanBase 对 TRUNCATE TABLE 并行能力的支持存在差异。

• 在 3.x 及更早版本中，TRUNCATE TABLE 操作在租户内串行执行，批量清理大量小表时可能成为性能瓶颈。此时，采用并发 DELETE 并分批提交，通常能获得更优的清理效率。

• 在 4.x 及以上版本中，已支持 TRUNCATE TABLE 并行执行，批量清表效率大幅提升。

本文将结合实际测试示例，拆解不同版本下批量清表的痛点与解决方案，为不同版本的 OceanBase 提供针对性的最佳实践，帮助运维人员在严格的时间窗口内高效完成数据清理。请注意，文中测试结果仅供参考，实际效果需结合您的业务环境和系统配置进行评估。

一、业务场景特点

• 大量小表：典型系统含有数百至数千张表。

• 数据量小：单表数据量通常在几百至几万行。

• 频繁清表：日终、月末等时间点需要批量清理数据。

• 时间窗口要求严格：业务处理时间窗口紧张，数据清理效率直接影响后续业务处理。

二、问题痛点

传统 TRUNCATE TABLE 方式的局限表现在以下几个方面：

值得注意的是，只有支持并行的 DDL 执行过程中才能并行。如果您插入了串行 DDL，则整体 DDL 执行将转为串行。因此，在 TRUNCATE TABLE 执行过程中最好仅包含支持并行的 DDL。如果有其他 DDL，您需要查看是否支持并行。

清表效率不足将会引发性能瓶颈凸显、批处理窗口延长、系统资源利用率失衡等连锁问题，影响后续业务处理。解决方案包括以下几种：

1、批处理设计

-- 创建表存储需要处理的表名CREATE TABLE tables_to_clean (table_name VARCHAR(100));INSERT INTO tables_to_clean VALUES ('fund_daily_position'), ('fund_transaction'), ...;-- 动态生成并执行 DELETE 语句BEGIN  FOR r IN (SELECT table_name FROM tables_to_clean) LOOP    EXECUTE IMMEDIATE 'DELETE FROM ' || r.table_name;  END LOOP;END;

• 创建临时表存储需要处理的表名

• 动态生成并执行 DELETE 语句

2、并行度调整

-- 设置会话级别并行度SET ob_sql_work_area_percentage = 30;  -- 增加工作区内存SET parallel_servers_target = 16;         -- 设置并行度

• 设置会话级别并行度

• 增加工作区内存

• 设置适当并行度

3、会话并行

• 使用多会话并发执行 DELETE 操作

• 根据表数量动态分配会话组

4、事务管理

-- 分批提交，避免单个大事务BEGINFOR i IN 1..10 LOOP   -- 每批处理部分表   DELETE FROM table_group_1;   DELETE FROM table_group_2;   COMMIT;  -- 阶段性提交END LOOP;END;

• 分批提交，避免单个大事务

• 每批处理部分表

• 阶段性提交

三、性能测试

测试环境如下：

• OceanBase 4.3.5 版本

• 集群配置：单节点单副本，每节点 16 核 64G

• 测试数据集：100 张表，每表 1000 行数据

• 租户规格：CPU 为 8C，内存为 32G。cpu_quota_concurrency 值为 4。

测试结果显示如下：

从上表可以看出：

• TRUNCATE TABLE（串行）方式耗时 8 秒

• TRUNCATE TABLE 方式（并行）耗时 1.2 秒

• 带分批提交的 DELETE 方式耗时 2 秒

• TRUNCATE TABLE（并行）的 TPS（83,333）高于其他两种方式

• TRUNCATE TABLE（并行）的性能优于其他两种方式

在真实环境中的性能表现会因以下因素而有显著差异：

• 实际的硬件配置和系统负载

• OceanBase 数据库具体版本和配置参数

• 表结构、索引数量和约束类型

• 实际数据量和数据分布特征

您可以使用以下方式监控性能指标：

-- 监控执行情况SELECT * FROM gv$session_longops WHERE opname LIKE '%DELETE%';-- 监控资源使用SELECT * FROM gv$sysstat WHERE name LIKE '%parallel%';

在您实施任何优化方案前，建议在与生产环境相似的测试环境中进行实际测试，以获取准确的性能数据。

以上测试结果仅为特定环境下的示例，实际效果需结合您的业务环境和系统配置进行评估。

四、结论

在 OceanBase 数据库环境下处理批量小表数据清理时，使用并行 TRUNCATE TABLE 策略在 4.x 版本下可以显著提升系统性能和资源利用率。在 3.x 版本中，建议使用带分批提交的 DELETE 方法。通过合理设计批处理逻辑和并行度，可以缩短批量清表操作的时间窗口，为业务处理提供更充裕的时间保障。具体建议如下：

• OceanBase 4.x：推荐使用并行 TRUNCATE TABLE；

• OceanBase 3.x：推荐使用带分批提交的 DELETE；

• 根据不同版本选择最优清表策略，提升系统整体性能。

此最佳实践特别适用于表数量多但单表数据量小的业务场景，可有效解决 OceanBase 中 TRUNCATE TABLE 操作不能并行的局限性，缩短批处理窗口，为后续业务预留充足时间，最终实现系统资源的均衡利用与业务连续性的可靠保障。