MatrixOne 关系接口重构：支持Prepare模式复用

背景

在MatrixOne数据库系统中，Relation接口是处理数据表操作的核心组件之一。当前实现中，Relation与事务状态和其他运行时上下文紧密耦合，导致无法在SQL Prepare阶段预先创建并保存Relation实例，而必须在每次Execute时重新生成。这种设计带来了不必要的性能开销，特别是在需要重复执行相同预处理语句的场景下。

问题分析

Relation接口的当前实现存在以下主要限制：

1. 事务状态耦合：Relation实例与特定事务绑定，无法跨事务复用
2. 运行时依赖：实例化过程依赖执行时上下文，无法提前准备
3. 资源管理复杂：锁等资源与Relation生命周期绑定，难以分离

这些问题使得预处理语句无法充分利用Relation实例的复用潜力，导致重复的初始化开销。

重构方案

核心思想

重构的核心是将Relation接口设计为两个层次：

1. 静态结构层：包含表定义、元数据等不变信息，可在Prepare阶段创建
2. 动态上下文层：包含事务状态、锁等运行时信息，在Execute阶段注入

具体实现

1. 接口分离：

   • 定义StaticRelation接口，包含表结构等静态信息
   • 现有Relation接口扩展为包含运行时上下文

2. 资源管理重构：

   • 将锁等资源的管理从Relation中解耦
   • 使用工厂模式按需创建运行时相关组件

3. 执行流程调整：

   • Prepare阶段创建StaticRelation并缓存
   • Execute阶段基于缓存的StaticRelation快速构建完整Relation

影响范围

重构涉及多个关键组件：

1. 数据源扫描：TableScan算子的Relation处理
2. 元数据锁定：lock_meta机制的重构
3. DML操作：multi_update、insert、delete等算子的适配
4. 锁操作：lock_op算子的调整

技术挑战

1. 线程安全：确保缓存的StaticRelation在多线程环境下安全访问
2. 资源泄漏：正确处理动态资源的生命周期
3. 性能平衡：权衡预处理开销与执行效率
4. 向后兼容：保持现有API的兼容性

预期收益

1. 性能提升：减少重复初始化开销，特别是高频预处理语句
2. 资源优化：降低内存占用，提高缓存利用率
3. 架构清晰：分离关注点，提高代码可维护性
4. 扩展性增强：为未来优化如计划缓存等特性奠定基础

实施路线

1. 第一阶段：重构Relation核心接口，使其支持静态化
2. 第二阶段：调整编译器与执行器，支持Relation缓存
3. 第三阶段：逐步优化各算子实现，适配新接口
4. 第四阶段：性能测试与调优

总结

MatrixOne对Relation接口的重构是提升预处理语句性能的关键改进。通过分离静态结构与运行时上下文，系统能够在Prepare阶段完成更多准备工作，显著减少执行阶段的开销。这一改进不仅提升了当前性能，也为未来优化如执行计划缓存等特性提供了良好的架构基础。