Oracle 租户事务型临时表实现细节

总结说明

Oracle 租户下，事务型临时表（ON COMMIT DELETE ROWS）的数据主要存储在内存中。事务提交或回滚时，系统会在 COMMIT 操作的同时开启内部事务，以 1000 行为一个批次循环执行 DELETE 操作来清除数据，此过程不写入 Clog。数据在转储时可能落盘至 SSTable，事务结束时执行的 DELETE 操作也会清理已落盘的数据。自 V4.2.0 版本起支持动态采样以优化执行计划，V4.2.2 版本起对事务临时表的逻辑进行了调整。

详细说明

概念定义

事务型临时表是指使用 ON COMMIT DELETE ROWS 选项创建的全局临时表（此选项为默认选项）。其数据生命周期与事务绑定，在事务提交或回滚后，数据会自动被清除。

使用场景

• 存储事务处理过程中的中间结果，事务结束即释放。
• 多会话并发处理，各会话数据需要隔离的场景。
• 不需要跨事务持久化的临时数据处理。

使用方法

事务级临时表

创建语法：

CREATE GLOBAL TEMPORARY TABLE temp_table_name (
  col1 datatype,
  col2 datatype,
  ...
) ON COMMIT DELETE ROWS;

ON COMMIT DELETE ROWS 为默认选项，可以省略。

示例：

CREATE GLOBAL TEMPORARY TABLE temp_order (
  order_id NUMBER,
  amount NUMBER
) ON COMMIT DELETE ROWS;

-- 会话A：插入数据，事务内可见
INSERT INTO temp_order VALUES (1, 100);
SELECT * FROM temp_order;  -- 可查到数据

-- COMMIT 后数据自动清除
COMMIT;
SELECT * FROM temp_order;  -- 无数据

-- 会话B：与会话A数据隔离，互不可见

数据存储与隔离机制

执行计划表现

验证动态采样：

EXPLAIN EXTENDED SELECT * FROM temp_order;
-- 查看 Optimization Info 中的 estimation method
-- 若为 DYNAMIC SAMPLING 则表示使用了动态采样

注意事项

1. 大数据量清理耗时：事务结束时以 1000 行/批循环执行 DELETE 清理，若临时表数据量很大，清理耗时较久，可能影响性能。
2. 高并发密集 COMMIT 风险：当每个 Session 的事务时间短、COMMIT 操作密集时，频繁的批量清理可能带来性能压力。
3. 数据可能落盘 SSTable：临时表数据不写 Clog，但转储时可能落盘 SSTable。实例异常重启后，MemTable 中的数据会丢失；若数据已落盘 SSTable，重启后可能残留，需通过后续的 DELETE 机制清理。
4. 版本选择：3.x 版本临时表 BUG 较多，建议使用 4.x 较高版本（如 V4.3.5+）。自 V4.2.2 起，事务临时表逻辑有调整，在性能敏感场景中可考虑使用实体表替代。
5. 执行计划调优：V4.2.0 以下版本缺乏动态采样，当不同会话数据量差异大时，需关注执行计划质量，必要时进行手动干预。

实战建议

1. 版本选择：3.x 版本临时表 BUG 较多，建议使用 V4.3.5 及以上版本。
2. 数据量大：若临时表数据量很大，可考虑使用实体表替代，以避免事务结束时的清理耗时。
3. 高并发短事务：在高并发、短事务的场景中，需关注批量清理对性能的影响，必要时进行压测验证。

适用版本

OceanBase 数据库 OBServer 3.x 版本，4.x 版本。