OceanBase 数据库批量数据清理策略最佳实践

在 OceanBase 数据库中，批量清理大量小表数据是常见的运维场景。不同版本的 OceanBase 对 TRUNCATE TABLE 并行能力的支持存在差异，这直接影响了批量清表的效率和最佳实践选择。

• OceanBase 3.x 及更早版本：TRUNCATE TABLE 操作在租户内为串行执行，批量清理大量小表时可能成为性能瓶颈。此时，采用并发 DELETE 并分批提交，通常能获得更优的清理效率。
• OceanBase 4.x 及以上版本：TRUNCATE TABLE 已支持并行执行，批量清表效率大幅提升，推荐优先采用并行 TRUNCATE TABLE。

本文将结合实际测试示例，分析不同方案在特定环境下的表现，并给出针对不同版本的最佳实践建议。请注意，文中测试结果仅供参考，实际效果需结合您的业务环境和系统配置进行评估。

业务场景特点

• 大量小表：典型系统含有数百至数千张表
• 数据量小：单表数据量通常在几百至几万行
• 频繁清表：日终、月末等时点需要批量清理数据
• 时间窗口要求严格：业务处理时间窗口紧张，数据清理效率直接影响后续业务处理

问题痛点

传统 TRUNCATE TABLE 方式的局限

• 串行执行限制：OceanBase 数据库 V3.X 中 TRUNCATE TABLE 操作在租户内不能并行执行
• 资源竞争：大量 TRUNCATE TABLE 操作会造成 DDL 资源争用
• 执行效率低：当需要清理数百张表时，串行执行导致总耗时线性增长

业务影响

• 清表操作成为系统性能瓶颈
• 延长批处理窗口，影响后续业务处理
• 系统资源利用率不均衡

解决方案

1. 批处理设计

   • 创建临时表存储需要处理的表名
   • 动态生成并执行 DELETE 语句

   -- 创建表存储需要处理的表名
   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;
   

2. 并行度调整

   • 设置会话级别并行度
   • 增加工作区内存
   • 设置适当并行度

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

3. 会话并行

   • 使用多会话并发执行 DELETE 操作
   • 根据表数量动态分配会话组

4. 事务管理

   • 分批提交，避免单个大事务
   • 每批处理部分表
   • 阶段性提交

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

性能测试

测试环境

• OceanBase V4.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 策略在 V4.X 版本下可以显著提升系统性能和资源利用率。在 V3.X 版本中，建议使用带分批提交的 DELETE 方法。通过合理设计批处理逻辑和并行度，可以缩短批量清表操作的时间窗口，为业务处理提供更充裕的时间保障。具体建议如下：

• OceanBase V4.X：推荐使用并行 TRUNCATE TABLE
• OceanBase V3.X：推荐使用带分批提交的 DELETE
• 根据不同版本选择最优清表策略，提升系统整体性能

此最佳实践特别适用于表数量多但单表数据量小的业务场景，可有效解决 OceanBase 数据库中 TRUNCATE TABLE 操作不能并行的局限性。

参考文档

• GV$SYSSTAT
• GV$SESSION_LONGOPS
• parallel_servers_target
• ob_sql_work_area_percentage