一条 SQL 从客户端进入 Observer 进程后，会先后经历「解析 → 改写 → 优化 → 代码生成」四个阶段。其中改写阶段（Rewrite）的核心目标是：在不改变 SQL 语义的前提下，把语句对象（ObDMLStmt）”重塑”成更易于优化器（CBO）处理的形态。本文聚焦 1247 行的 ob_transformer_impl.cpp——它把 30 余种改写规则（视图合并、子查询去关联、OR 展开、谓词下推、count 转 exists 等）收敛到一个统一的调度框架内，是改写阶段的总指挥。
在 OceanBase 的 SQL 编译流水线中，Parser 负责把 SQL 文本切成一棵 ParseNode 语法树；紧接其后的 Resolver 阶段则把这棵语法树”翻译”成带有 schema/类型/列引用信息的 ObStmt 语义树。src/sql/resolver/ob_resolver.cpp 就是这个语义解析阶段的总入口：所有 DML、DDL、DCL、TCL、命令语句（SHOW/SET/KILL 等）以及 PL 编译预处理都要经过它。
如果把 OceanBase 的 SQL 引擎比作一条流水线，src/sql/ob_sql.cpp 就是流水线的大门。所有外部 SQL——无论是普通文本协议、Prepared Statement，还是 PL 块里的内嵌 SQL——最终都会先汇聚到 ObSql 这个类，再被分发到解析器、解析器、改写器、优化器、代码生成器，最后拿到可执行的物理计划。本文聚焦这一”总入口”，把它的职责、核心数据结构、以及一条 SQL 从进门到出门的完整流程讲清楚。
本系列文章是对 OceanBase v4.3.5_CE_BP6 开源源码的逐模块深度解读。本文解读 observer 进程的启动流程，覆盖 main.cpp 和 ob_server.cpp 两个核心文件。
本文针对的群体，是已经对备份恢复的基本原理了解的用户群。笔者从内部使用，外部用户等渠道收集的相关备份和恢复过程比较常见的问题，进行了相关的排查经验梳理。对于刚接触备份恢复的用户，建议先去开源官网了解相关知识：OceanBase 备份与恢复 29
继续阅读物理备份恢复问题排查相关1、SQL改写系列一：OceanBase 查询改写实践
继续阅读oceanbase SQL查询改写