执行计划在 OceanBase 中被实现为一棵由操作符组成的“二叉树”（OceanBase 目前暂不支持操作自分支超过两个的“多元操作符”）。当查询涉及到多个关系（Relation）时，优化器会通过依次执行多个 join 操作，将多个关系连接在一起，最终完成执行。执行树从形状上可以分为“左深树”、“右深树”和“多枝树”三种（参见下图），目前 OceanBase 的优化器只支持左深树的计划生成。

物理操作符是执行计划的基本单元，多个物理操作符按照“二叉树”的形式组成一个完整的执计划。

执行计划的生成过程非常复杂，优化器需要综合考虑多种因素，为 SQL 生成“最佳”的执行计划。因此，查询优化的过程本身也是一个比较耗时的过程，当 SQL 本身执行耗时较短时，查询优化所带来的开销也变得不可忽略。一般来说，数据库在这种场景会缓存之前生成的执行计划，以便在下次执行该 SQL 时直接使用，这种策略被称为“optimize once”，即“一次优化”。实际场景中，“一次优化”的策略虽然可以大大降低每次执行时优化的开销，但也会引入一些问题。例如，当同一条 SQL 不同的参数值需要使用不同计划时，“一次优化”的策略就无法处理。针对这种场景，OceanBase 2.0 引入了自适应计划共享（Adaptive Cursor Sharing）功能，能够较好地处理不同参数条件下的计划选择。