上一篇发出去，有朋友私信我，源码拉下来了，打开一看傻眼了。几千个文件，几十万行起步的体量，从哪下嘴？

这个感觉我太熟了。当年刚翻 OB 代码的时候我也这样，对着目录树发了半小时呆。后来摸到一套方法，核心就一句话，别读代码，跟代码。找一条最简单的 SQL，让它牵着你走一遍，走通一次，骨架就有了。这篇把这套方法讲透，后面三十几篇的源码分析全是这么跑出来的。

![](https://developer.qcloudimg.com/http-save/yehe-7380306/fc8e2445795f0905be045a918be9c1f9.png)

三件工具，一个不能少

第一件，带调试符号的 observer。上一篇用 `build.sh debug` 编出来的就是它。release 版符号被优化掉，gdb 进去只剩汇编，变量名都看不见。

第二件，代码导航。我图省事用 ripgrep，找函数定义，`rg "int ObSql::stmt_query" src/sql` 一秒出结果。VS Code、CLion 配索引也行，看个人习惯，别在这上面纠结。

第三件，OB 自己的日志和 trace\_id。这是 OB 比很多数据库友好的地方，每条 SQL 有 trace\_id，往 observer.log 里一搜，这条 SQL 在服务端的轨迹全捞出来。gdb 是显微镜，trace\_id 是导航图，两个配合着用。

## 入口在哪，先看一眼真身

SQL 从客户端发出来，第一个接住它的是协议层，`src/observer/mysql` 目录，负责把 MySQL 协议的字节流拆成内部请求。这里我不建议细看，协议解析是体力活，知道它在这就行。

真正的总调度在 `src/sql/ob_sql.cpp`。这个文件头部有三个函数，是 SQL 一生的起点。stmt\_prepare 在 133 行，管预处理语句。stmt\_query 在 155 行，管普通文本查询。stmt\_execute 在 208 行，管预处理执行。文本协议来的 SQL 走 stmt\_query，PreparedStatement 走 prepare 加 execute 两步，这个分叉后面第 5 篇讲 plan cache 时还会回来。

把 stmt\_query 的开头几行拉出来看（ob\_sql.cpp:155-175）：

```bash
int ObSql::stmt_query(const common::ObString &stmt, ObSqlCtx &context, ObResultSet &result)
{
  int ret = OB_SUCCESS;
  LinkExecCtxGuard link_guard(result.get_session(), result.get_exec_context());
  FLTSpanGuard(sql_compile);
  ObMemPerfGuard mem_perf_guard("sql_compile");
  {
    ObTruncatedString trunc_stmt(stmt);
    ...
    NG_TRACE(parse_begin);
    //1 check inited
    if (OB_FAIL(sanity_check(context))) {
      LOG_WARN("Failed to do sanity check", K(ret));
    } else if (OB_FAIL(handle_text_query(stmt, context, result))) {
      ...
    }
```

逐行说。第一行签名，三个参数各管一件事，stmt 是 SQL 文本，context 攒着这条 SQL 的上下文，result 是结果集，后面所有阶段的产出都往这里面装。`LinkExecCtxGuard` 把 session 和执行上下文挂上，OB 代码里大量这种 RAII 守卫，出了作用域自动清理，看代码时认出这个套路能省很多事。`FLTSpanGuard(sql_compile)` 和 `NG_TRACE(parse_begin)` 是追踪埋点，全链路诊断的 show trace 能展示每个阶段耗时，靠的就是这些钉子。`ObTruncatedString` 是个贴心的细节，日志里打 SQL 最多截一段，防止一条几兆的 SQL 把日志灌爆。最后的 `sanity_check` 加 `handle_text_query`，真正的活全在后者里面。

读完这二十行，你已经摸清 OB 代码的三个脾气，守卫模式满天飞、埋点无孔不入、主逻辑都藏在 handle\_xxx 里。这个脾气后面每一篇都会遇到。

## 五道关，断点这么下

从 ObSql 往下，一条 SQL 要过五道关，每道关对应 src/sql 下的一个目录。parser 做词法语法解析，resolver 做语义解析，把表名列名对上真实的数据库对象，transformer 做查询改写，代码在 rewrite 目录，optimizer 生成执行计划，executor 加 engine 负责执行。

我第一次跟的时候，在每关入口各下一个断点，发一条 `select * from t1 where id = 1`，反复 continue。每停一次做两件事，`bt` 看调用栈，print 看关键结构。比如 resolver 出来之后，stmt 对象里的表和列已经对上 schema 里的真实对象了，看一眼就知道语义解析干了什么。

整个链路画出来是这样的：

![](https://developer.qcloudimg.com/http-save/yehe-7380306/cf579f353ba1a873c58969aedddbcf26.png)

注意图里那条短路线，plan cache 命中时，parser 到 optimizer 四关全跳。这段短路在代码里写得明明白白，看 handle\_sql\_execute 的片段（ob\_sql.cpp:1868-1888）：

```bash
    if (!use_plan_cache) {
      // do nothing
    } else if (OB_FAIL(pc_get_plan_and_fill_result(pc_ctx, result,
                         get_plan_err, ectx.get_need_disconnect_for_update()))) {
      LOG_WARN("failed to get plan", K(ret));
    }
  }

  if (OB_SUCC(ret)) {
    if (!result.get_is_from_plan_cache()) {
      ...
      if (OB_FAIL(handle_physical_plan(raw_sql, context, result, pc_ctx, get_plan_err))) {
```

逐行看。先问 session 开没开 plan cache，开了就调 `pc_get_plan_and_fill_result` 去缓存里找计划。找到之后，`result.get_is_from_plan_cache()` 就是真，下面那个 if 进不去，handle\_physical\_plan 整个被跳过。handle\_physical\_plan 里面装的就是 parser 到 optimizer 那四关。命中即跳过，四个字在这里是物理事实。

这段代码还解释了新手跟代码时最容易懵的一件事，第二次执行同一条 SQL，你在 optimizer 下的断点根本不停。第一次跟的时候别被搞懵，先 `alter system flush plan cache` 清掉缓存再跟，保证走完整路径。

## 上手跟一遍，命令照抄

环境就绪后，动手的顺序是这样。

先找到 observer 进程号，`ps -ef | grep observer`。然后 `gdb -p <pid>` 挂上去。下断点：

```bash
b oceanbase::sql::ObSql::stmt_query
c
```

另开一个窗口，obclient 连上，发一条 `select * from t1 where id = 1`。gdb 窗口停住了，`bt` 看栈，你会看到从协议层一路下来的调用链，十几层很正常。继续 `c`，配合在 parser、resolver、optimizer 各下的断点，一站一站踩过去。

跟一遍一两个小时。跟完你会发现课件上那张执行流程图突然有血有肉了，每个框都对应你亲眼见过的函数。

## 四条心得，都是踩坑踩出来的

从简单 SQL 开始。`select 1` 太短不过瘾，多表 join 又太绕。最好的第一条是单表主键点查，路径完整，干扰最少。

调用栈比单步重要。新手容易陷在单步里出不来。我的经验是多下断点少单步，到了关键函数 `bt` 看栈，知道"我被谁调来的"，比知道"下一行是什么"重要得多。OB 的调用层次深，单步跟半小时可能还在同一个函数里打转。

日志和代码对照看。observer.log 里每个 ERROR、WARN 都能在代码里找到输出点。看到看不懂的报错，把报错文本拿去搜，直接定位到抛错那一行，上下文读五十行，方向就有了。这是排查问题最快的路径，没有之一。

允许自己看不懂。OB 代码里模板和宏用得很多，存储层那些模板嵌套，我第一次看也是懵的。看不懂就跳过，保证主链路不断。骨架熟了，细节以后有的是机会补。读源码这事，先求全再求精，顺序反了容易弃坑。

## 面试怎么答，生产怎么查

面试被问"一条 SQL 在 OceanBase 里的完整执行流程"，按五阶段答完，主动补一句"plan cache 命中时前四阶段会跳过"，再补一句"我用 gdb 跟过这条链路"。这三句话的杀伤力是递进关系，第三句一出，面试官基本就换话题了。

生产上这套方法有个直接用途，报错定位。任何看不懂的报错文本，搜到抛错行，读上下文，八成的问题在这一步就有方向。还有一个隐蔽用途，看 trace。show trace 里每个阶段的 span 名字，跟代码里的 FLTSpanGuard、NG\_TRACE 埋点一一对应，读懂 trace 的最快方式就是在代码里搜这些埋点名。

## 留给你的三个思考题

1.  面试官问"PreparedStatement 和普通查询在服务端的处理有什么差别"，你能从 stmt\_prepare 和 stmt\_query 两个入口讲开吗？plan cache 在两条路径上的命中逻辑一样吗？
    
2.  一条 SQL 在 parser 阶段就报错，比如语法写错了，它会占用 plan cache 的空间吗？想想 plan cache 的 key 是什么，parser 挂了之后有没有 key 产生。
    
3.  生产上遇到过"计划没变但 SQL 变慢"吗？按五道关的框架，如果问题不在这五关里，它最可能在链路之外的什么地方？（提示，想想执行阶段的等待事件）

上一篇发出去，有朋友私信我，源码拉下来了，打开一看傻眼了。几千个文件，几十万行起步的体量，从哪下嘴？

gdb 跟踪第一条 SQL，读 OB 源码的正确姿势

当年刚翻 OB 代码的时候我也这样，对着目录树发了半小时呆。后来摸到一套方法，核心就一句话，别读代码，跟代码。找一条最简单的 SQL，让它牵着你走一遍，走通一次，骨架就有了。这篇把这套方法讲透，后面三十几篇的源码分析全是这么跑出来的。

数据库

找一条简单SQL，从stmt_query入口进入，跟代码不读代码。gdb加trace_id定位，断点下在parser、resolver、optimizer等五道关。plancache命中时跳过前四关，可flush清除缓存。此方法已产出三十余篇源码分析，助你快速建立OB代码骨架认知。

代码解释

Transformer

MySQL

文章

问答

视频

教程

学习中心

腾讯云实验室

直播

竞赛

腾讯云代码分析专区

腾讯iOA零信任安全管理系统专区

腾讯云架构师技术同盟交流圈

腾讯云数据库专区

腾讯云智能顾问专区

腾讯云原生专区

腾讯混元专区

腾讯云TCE专区

腾讯云Lighthouse专区

腾讯云HAI专区

腾讯云Edgeone专区

腾讯云存储专区

腾讯云智能专区

腾讯轻联专区 

腾讯云开发专区

TAPD专区

腾讯轻量云游戏服专区

EdgeOne AI 安全实战专区

腾讯云最具价值专家

腾讯云架构师技术同盟

腾讯云创作之星

腾讯云开发者先锋

腾讯云代码助手

云原生构建

TAPD 敏捷项目管理

Cloud Studio

SDK中心

API中心

命令行工具

涵盖代码开发、场景应用、自动测试全流程，助你从零构建专属AI助手

一站式MCP教程库，解锁AI应用新玩法

聚焦“写作效率、视觉美观与运行性能”三方面进行全面升级，为您提供更高效、稳定的创作环境

社区富文本&Markdown编辑器全新改版上线，欢迎大家体验!

诚挚邀请您参与本次调研，分享您的真实使用感受与建议。您的反馈至关重要，感谢您的支持与参与！

社区新版编辑器体验调研

gdb 跟踪第一条 SQL，读 OB 源码的正确姿势-腾讯云开发者社区-腾讯云

gdb 跟踪第一条 SQL，读 OB 源码的正确姿势

gdb 跟踪第一条 SQL，读 OB 源码的正确姿势

社区

活动

圈层

关于

腾讯云开发者

热门产品

热门推荐

更多推荐