TiDB源码学习笔记：制定计划

浅浅的花香味﹌ 2023-10-03 10:25 12阅读 0赞

> TiDB源码研究系列第四篇，从一句SQL出发，探索SQL计划制定的流程与原理。

距离上一次源码笔记已经有一个多星期了，中间处理了一些其他的事情，放在源码阅读上的时间不多，又因为到了计划制定这一个模块后，代码复杂度明显增加，所以学习起来也是相当困难，万事开头难，坚持一下，反复阅读还是会有很多收获的。这篇文章主要记录的是通过AST制定查询计划的大概流程，涉及到的内容部分会不做深入，比如计划优化，全局跟踪，参数处理等。

回顾一下以前的笔记 [SQL的一生][SQL]中，SQL在经历解析模块生成AST后，下一步便是通过AST辨别类型，制定计划，计划分为两种，逻辑计划和物理计划。因为TiDB是分布式关系型数据库，与传统的关系型数据库不同，作为分布式系统，在制定SQL计划的时候，需要考虑到扩展性，容错性和可靠性等特点，为了更好的发挥分布式系统的优势，并尽量缩小其缺陷，需要先制定逻辑计划，然后对逻辑计划进行拆分，转换为物理计划后在多个节点上并行运算。

光讲也没啥用，听不懂的还是听不懂，我们直接走源码，跟着源码的实现来理解这个过程是如何进行的。这里我们还是跑一句SQL，然后断点跟踪，理解它每一步的意义。

SQL：”select \* from student where id = 1”（注意：SQL的处理引擎是非常复杂的，因为SQL语句的形式和语法非常的多，我们在这里是处理其中一句简单的SQL来学习其过程，意义是为了去了解整体的架构和思想，对于不同的语句类型和语法，处理是会有区别的，所以想要深入的去了解每一个的实现，还需要下足够的功夫，在这里我们选择入门式的学习，为的是更快的上手源码，所以不会面面都涉及到）

进入源码，首先启动TiDB，打上断点（这个在前面笔记中都有讲解）断点位置到 executor/compiler.go:49 func (c \*Compiler) Compile(ctx context.Context, stmtNode ast.StmtNode) (\*ExecStmt, error)这个方法，运行到这里

// Compile compiles an ast.StmtNode to a physical plan.
    func (c *Compiler) Compile(ctx context.Context, stmtNode ast.StmtNode) (*ExecStmt, error) {
       ......
     
       infoSchema := infoschema.GetInfoSchema(c.Ctx)
       // 解析表名并进行语句基本结构的校验
       if err := plannercore.Preprocess(c.Ctx, stmtNode, infoSchema); err != nil {
          return nil, err
       }
       // 尝试添加额外限制
       stmtNode = plannercore.TryAddExtraLimit(c.Ctx, stmtNode)
        // 优化并生成计划
       finalPlan, names, err := planner.Optimize(ctx, c.Ctx, stmtNode, infoSchema)
       if err != nil {
          return nil, err
       }
        // 记录语句类型
       CountStmtNode(stmtNode, c.Ctx.GetSessionVars().InRestrictedSQL)
       var lowerPriority bool
       if c.Ctx.GetSessionVars().StmtCtx.Priority == mysql.NoPriority {
          lowerPriority = needLowerPriority(finalPlan)
       }
       return &ExecStmt{
          GoCtx:         ctx,
          InfoSchema:    infoSchema,
          Plan:          finalPlan,
          LowerPriority: lowerPriority,
          Text:          stmtNode.Text(),
          StmtNode:      stmtNode,
          Ctx:           c.Ctx,
          OutputNames:   names,
       }, nil
    }

这个方法的注释也是非常的直白，将一个AST转换为一个物理计划，简化代码分为了三步，首先解析表名，对语句的基本结构进行校验，然后添加一些额外的限制，这个需要在 sql\_select\_limit 这个参数设置的时候才会添加，这个参数会设置每次查询最大的返回数量，默认是关闭的，一般不使用。下一步是重点关注的，优化并生成最终计划，需要跟进去看一下，但是进去之前，我们先研究一下AST的结构，“Select \* from student where id = 1"解析成的AST结构如何

![watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L0NCR0NhbXB1cw_size_16_color_FFFFFF_t_70][]

结构非常的明了，上面能看到我们的原始句子，下面有三个小节点可以关注下，From，Where，Fields，因为我们这一句主要涉及到这三个部分

![watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L0NCR0NhbXB1cw_size_16_color_FFFFFF_t_70 1][]

From中左节点的Source中记录了表名信息，Name中的O 和 L 分别表示 Original 和 Lower， 原始和小写形式

![watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L0NCR0NhbXB1cw_size_16_color_FFFFFF_t_70 2][]

Where中有左右两个节点，左节点记录了字段名 id， 右节点则记录了值 1，上面有一个Op参数，则是记录的操作符，EQ表示等于，左右节点相等。组合起来就是id = 1。

![watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L0NCR0NhbXB1cw_size_16_color_FFFFFF_t_70 3][]

Field 比较简单，是一个列表，记录每一个字段，这个地方因为是“select \* ” 是选择的所有字段，所以是空字符串，大家可以试试填具体字段会如何显示。

了解了AST树结构后我们回到代码之中，进入 finalPlan, names, err := planner.Optimize(ctx, c.Ctx, stmtNode, infoSchema) 这个方法中

// Optimize does optimization and creates a Plan.
    // The node must be prepared first.
    func Optimize(ctx context.Context, sctx sessionctx.Context, node ast.Node, is infoschema.InfoSchema) (plannercore.Plan, types.NameSlice, error) {
       sessVars := sctx.GetSessionVars()
     
       // 首先会判断是否启用TiFlash
       // Because for write stmt, TiFlash has a different results when lock the data in point get plan. We ban the TiFlash
       // engine in not read only stmt.
       if _, isolationReadContainTiFlash := sessVars.IsolationReadEngines[kv.TiFlash]; isolationReadContainTiFlash && !IsReadOnly(node, sessVars) {
          delete(sessVars.IsolationReadEngines, kv.TiFlash)
          defer func() {
             sessVars.IsolationReadEngines[kv.TiFlash] = struct{}{}
          }()
       }
     
       // 是否使用的TiKV
       if _, isolationReadContainTiKV := sessVars.IsolationReadEngines[kv.TiKV]; isolationReadContainTiKV {
          var fp plannercore.Plan
          // 判断快速计划是否已经使用过
          if fpv, ok := sctx.Value(plannercore.PointPlanKey).(plannercore.PointPlanVal); ok {
             // point plan is already tried in a multi-statement query.
             fp = fpv.Plan
          } else {
             // 尝试使用快速计划
             fp = plannercore.TryFastPlan(sctx, node)
          }
          // 如果可以使用快速计划，则直接返回快速计划
          if fp != nil {
             if !useMaxTS(sctx, fp) {
                sctx.PrepareTSFuture(ctx)
             }
             return fp, fp.OutputNames(), nil
          }
       }
     
       // 准备未来时间戳
       sctx.PrepareTSFuture(ctx)
     
       // 从树节点中获取提示，记录警告
       ......
     
       // 生成最佳计划
       bestPlan, names, _, err := optimize(ctx, sctx, node, is)
       if err != nil {
          return nil, nil, err
       }
     
     
       // 判断是否开启计划基线和基线发展
       if !(sessVars.UsePlanBaselines || sessVars.EvolvePlanBaselines) {
          return bestPlan, names, nil
       }
       // 如果开启了计划基线和基线发展，则会基于基线进行优化
       ......
    }

方法很长，有130多行，涉及内容也比较多，我简化了一下代码，因为部分内容暂且可以先不管，比如后面的计划基线，这个是在计划制定完成后，进行的一些操作，不是我们这次的重点，而且关于计划基线内容比较多，大家有兴趣可以深入了解下，其主要是用来固定给定SQL语句的执行计划，避免在环境有所改变的时候，在制定一个已经执行过的SQL语句的新计划反而比以前计划要慢的情况。去掉这部分后，再来看看，首先进入方法中会有两个判断，判断是否启用的TiFlash或TiKV，TiFlash是TiDB架构中用于OLAP的存储引擎，这里也不多讲了，后面判断启用TiKV，也就是我们现在的状态，会有快速计划判断，如果SQL满足一定的条件，就可以直接生成计划，避免优化和协处理消耗，节约资源。那么疑问来了，满足什么要求？其实我们现在这一句“Select \* from student where id = 1”就满足PointGetPlan，我们看一下注释中是怎么解释的:

// tryPointGetPlan determine if the SelectStmt can use a PointGetPlan.
    // Returns nil if not applicable.
    // To use the PointGetPlan the following rules must be satisfied:
    // 1. For the limit clause, the count should at least 1 and the offset is 0.
    // 2. It must be a single table select.
    // 3. All the columns must be public and generated.
    // 4. The condition is an access path that the range is a unique key.
    func tryPointGetPlan(ctx sessionctx.Context, selStmt *ast.SelectStmt) *PointGetPlan {
       ......
    }

需要满足四个规则：第一个limit条件至少为1，且位移为0，第二个是单表查询，第三个是选择的所有列必须都是公开的和生成的，最后一个规则是语句中的条件只有一个，必须是唯一键且为等号（我是这么理解的，可能会有偏差）。回头看我们这句SQL："Select \* from student where id = 1"完全满足这四个条件，所以在继续跟踪断点后，会发现在这里会直接生成计划返回。快速生成计划这个内容也比较多，代码我没有展开去详细的看，因为这也属于一种优化方式，以后再深入，现在还是继续走主要流程，理解整体架构和流程，接下来我们将SQL改为“Select \* from student where name = 'jk'”不使用id的唯一索引，就不满足上面的最后一个规则了，我们重新跟踪断点，继续往下走，会走到 bestPlan, names, \_, err := optimize(ctx, sctx, node, is) 这个方法中，进去看一下

func optimize(ctx context.Context, sctx sessionctx.Context, node ast.Node, is infoschema.InfoSchema) (plannercore.Plan, types.NameSlice, float64, error) {
       // build logical plan
       sctx.GetSessionVars().PlanID = 0
       sctx.GetSessionVars().PlanColumnID = 0
       hintProcessor := &hint.BlockHintProcessor{Ctx: sctx}
       node.Accept(hintProcessor)
       builder := plannercore.NewPlanBuilder(sctx, is, hintProcessor)
     
       // reset fields about rewrite
       sctx.GetSessionVars().RewritePhaseInfo.Reset()
       beginRewrite := time.Now()
       // 构建物理计划
       p, err := builder.Build(ctx, node)
       if err != nil {
          return nil, nil, 0, err
       }
       sctx.GetSessionVars().RewritePhaseInfo.DurationRewrite = time.Since(beginRewrite)
     
       sctx.GetSessionVars().StmtCtx.Tables = builder.GetDBTableInfo()
       activeRoles := sctx.GetSessionVars().ActiveRoles
       // Check privilege. Maybe it's better to move this to the Preprocess, but
       // we need the table information to check privilege, which is collected
       // into the visitInfo in the logical plan builder.
       if pm := privilege.GetPrivilegeManager(sctx); pm != nil {
          if err := plannercore.CheckPrivilege(activeRoles, pm, builder.GetVisitInfo()); err != nil {
             return nil, nil, 0, err
          }
       }
     
       if err := plannercore.CheckTableLock(sctx, is, builder.GetVisitInfo()); err != nil {
          return nil, nil, 0, err
       }
         
       // Handle the execute statement.
       if execPlan, ok := p.(*plannercore.Execute); ok {
          err := execPlan.OptimizePreparedPlan(ctx, sctx, is)
          return p, p.OutputNames(), 0, err
       }
     
       names := p.OutputNames()
       
       // Handle the non-logical plan statement.
       logic, isLogicalPlan := p.(plannercore.LogicalPlan)
       if !isLogicalPlan {
          return p, names, 0, nil
       }
      
       // Handle the logical plan statement, use cascades planner if enabled.
       if sctx.GetSessionVars().GetEnableCascadesPlanner() {
          finalPlan, cost, err := cascades.DefaultOptimizer.FindBestPlan(sctx, logic)
          return finalPlan, names, cost, err
       }
     
       beginOpt := time.Now()
       finalPlan, cost, err := plannercore.DoOptimize(ctx, sctx, builder.GetOptFlag(), logic)
       sctx.GetSessionVars().DurationOptimization = time.Since(beginOpt)
       return finalPlan, names, cost, err
    }

方法名叫优化，其实里面构建了物理计划然后优化成逻辑计划，我们一步一步的看，方法进来，现会初始化一个计划构建者 PlanBuilder ，这里有一个 Hints 的概念，直接翻译就是提示的意思，其实前面的基线处理也用到了这个概念，初步学习可能不理解什么意思，这是优化的一个手段，一般在优化查询的过程中是靠我们的优化器去进行判断和构建，但是优化器本身并没有那么的智能，有时候还是会选择比较笨的计划，所以最后产生一些非常差劲的计划，为了避免这个过程，我们可以写一些提示给优化器，当优化器遇到这些问题时，会去查看我们写入的Hints，使用指定的优化方法，从而避免选择差劲的计划，但是Hints尽量要少用，一是增加Hints需要直接修改代码，二是每个Hints只能修复一个SQL，三是随着版本更新变化Hints本身会落后和废弃。Hints 的具体实现在这不深入，有兴趣可以搜索一下。

继续看代码，初始化builder后，重置一下重写字段，调用Build方法构建一个物理计划，构建完成后检查用户权限和表是否被锁，都通过了则继续处理，判断语句的类型，当我们的语句为 Execute 类型则直接通过 execPlan.OptimizePreparedPlan(ctx, sctx, is) 方法进行处理生成计划，当前的语句是 Select 类型，所以会在这里跳过去，那如果计划在前面构建的时候已经构建成其他计划，并非逻辑计划，就可以直接返回。继续判断 Cascades Planner 是否开启，涉及到 Cascades 知识点，他是一个优化器，这里不进行深入讲解，可以看一下官方解释，需要一点基础知识才能看懂，比较硬核，后期有机会我也会深入学习关于优化模块，然后写一些 笔记记录学习过程

[揭秘 TiDB 新优化器：Cascades Planner 原理解析][TiDB _Cascades Planner]

如果没有开启Cascades优化器（现在是默认不开启的），则会通过 plannercore.DoOptimize(ctx, sctx, builder.GetOptFlag(), logic) 这个方法来将逻辑计划优化为物理计划，现阶段我们重点关注这个。

下面我先进入 builder.Build 来看一下它是如何构建一个逻辑计划的：

// Build builds the ast node to a Plan.
    func (b *PlanBuilder) Build(ctx context.Context, node ast.Node) (Plan, error) {
       b.optFlag |= flagPrunColumns
       switch x := node.(type) {
     
     
       ......
     
       case *ast.SelectStmt:
          if x.SelectIntoOpt != nil {
             return b.buildSelectInto(ctx, x)
          }
          return b.buildSelect(ctx, x)
        
       ......
       }
       return nil, ErrUnsupportedType.GenWithStack("Unsupported type %T", node)
    }

代码很简明，就是判断树节点的类型，通过类型构建不同的物理计划，现在查询的语句是Select类型，所以继续跟进就是 buildSelect(ctx, x) 方法

func (b *PlanBuilder) buildSelect(ctx context.Context, sel *ast.SelectStmt) (p LogicalPlan, err error) {
       ......
        
       // 构建查询计划中的数据源
       if sel.From != nil {
          p, err = b.buildResultSetNode(ctx, sel.From.TableRefs)
          if err != nil {
             return nil, err
          }
       } else {
          p = b.buildTableDual()
       }
        
       // 展开查询字段，将"*"展开
       originalFields := sel.Fields.Fields
       sel.Fields.Fields, err = b.unfoldWildStar(p, sel.Fields.Fields)
       if err != nil {
          return nil, err
       }
       // 判断是否能够修改AST结构，如果能修改就把展开后的字段直接放到AST中
       if b.capFlag&canExpandAST != 0 {
          originalFields = sel.Fields.Fields
       }
        
       // 解析查询计划中的GroupBy
       if sel.GroupBy != nil {
          p, gbyCols, err = b.resolveGbyExprs(ctx, p, sel.GroupBy, sel.Fields.Fields)
          if err != nil {
             return nil, err
          }
       }
       // 判断SQLMode是否开启了ONLY_FULL_GROUP_BY模式
       // 如果开启了，那么 Select 中出现的字段必须在 GroupBy 后面出现，否则报错
       if b.ctx.GetSessionVars().SQLMode.HasOnlyFullGroupBy() && sel.From != nil {
          err = b.checkOnlyFullGroupBy(p, sel)
          if err != nil {
             return nil, err
          }
       }
      
       // 解析窗口函数，作为Map供后面构建使用
       hasWindowFuncField := b.detectSelectWindow(sel)
       if hasWindowFuncField {
          windowAggMap, err = b.resolveWindowFunction(sel, p)
          if err != nil {
             return nil, err
          }
       }
       // 解析Having 和 OrderBy 生成 havingMap 和 orderMap
       // We must resolve having and order by clause before build projection,
       // because when the query is "select a+1 as b from t having sum(b) < 0", we must replace sum(b) to sum(a+1),
       // which only can be done before building projection and extracting Agg functions.
       havingMap, orderMap, err = b.resolveHavingAndOrderBy(sel, p)
       if err != nil {
          return nil, err
       }
     
       // b.allNames will be used in evalDefaultExpr(). Default function is special because it needs to find the
       // corresponding column name, but does not need the value in the column.
       // For example, select a from t order by default(b), the column b will not be in select fields. Also because
       // buildSort is after buildProjection, so we need get OutputNames before BuildProjection and store in allNames.
       // Otherwise, we will get select fields instead of all OutputNames, so that we can't find the column b in the
       // above example.
       b.allNames = append(b.allNames, p.OutputNames())
       defer func() { b.allNames = b.allNames[:len(b.allNames)-1] }()
     
       // 解析Where条件
       if sel.Where != nil {
          p, err = b.buildSelection(ctx, p, sel.Where, nil)
          if err != nil {
             return nil, err
          }
       }
       // 判断查询中的锁类型
       if sel.LockInfo != nil && sel.LockInfo.LockType != ast.SelectLockNone {
          if sel.LockInfo.LockType == ast.SelectLockInShareMode && !enableNoopFuncs {
             err = expression.ErrFunctionsNoopImpl.GenWithStackByArgs("LOCK IN SHARE MODE")
             return nil, err
          }
          p = b.buildSelectLock(p, sel.LockInfo)
       }
       b.handleHelper.popMap()
       b.handleHelper.pushMap(nil)
     
       // 构建查询计划中的聚合函数 会用到前面解析出来的 GroupBy
       hasAgg := b.detectSelectAgg(sel)
       if hasAgg {
          aggFuncs, totalMap = b.extractAggFuncs(sel.Fields.Fields)
          var aggIndexMap map[int]int
          p, aggIndexMap, err = b.buildAggregation(ctx, p, aggFuncs, gbyCols)
          if err != nil {
             return nil, err
          }
          for k, v := range totalMap {
             totalMap[k] = aggIndexMap[v]
          }
       }
     
       var oldLen int
       // According to https://dev.mysql.com/doc/refman/8.0/en/window-functions-usage.html,
       // we can only process window functions after having clause, so `considerWindow` is false now.
       p, oldLen, err = b.buildProjection(ctx, p, sel.Fields.Fields, totalMap, nil, false, sel.OrderBy != nil)
       if err != nil {
          return nil, err
       }
     
       // 解析Having关键字
       if sel.Having != nil {
          b.curClause = havingClause
          p, err = b.buildSelection(ctx, p, sel.Having.Expr, havingMap)
          if err != nil {
             return nil, err
          }
       }
        
       // 构建窗口规范
       b.windowSpecs, err = buildWindowSpecs(sel.WindowSpecs)
       if err != nil {
          return nil, err
       }
     
       // 通过前面解析出来的窗口函数
       // 这里构建窗口函数的查询计划
       // 最后会构建字段映射
       var windowMapper map[*ast.WindowFuncExpr]int
       if hasWindowFuncField {
          windowFuncs := extractWindowFuncs(sel.Fields.Fields)
          // we need to check the func args first before we check the window spec
          err := b.checkWindowFuncArgs(ctx, p, windowFuncs, windowAggMap)
          if err != nil {
             return nil, err
          }
          groupedFuncs, err := b.groupWindowFuncs(windowFuncs)
          if err != nil {
             return nil, err
          }
          p, windowMapper, err = b.buildWindowFunctions(ctx, p, groupedFuncs, windowAggMap)
          if err != nil {
             return nil, err
          }
          // Now we build the window function fields.
          p, oldLen, err = b.buildProjection(ctx, p, sel.Fields.Fields, windowAggMap, windowMapper, true, false)
          if err != nil {
             return nil, err
          }
       }
         
       // 构建Distinct
       if sel.Distinct {
          p, err = b.buildDistinct(p, oldLen)
          if err != nil {
             return nil, err
          }
       }
        
       // 构建OrderBy
       if sel.OrderBy != nil {
          p, err = b.buildSort(ctx, p, sel.OrderBy.Items, orderMap, windowMapper)
          if err != nil {
             return nil, err
          }
       }
     
       // 构建Limit
       if sel.Limit != nil {
          p, err = b.buildLimit(p, sel.Limit)
          if err != nil {
             return nil, err
          }
       }
     
       sel.Fields.Fields = originalFields
       if oldLen != p.Schema().Len() {
          proj := LogicalProjection{Exprs: expression.Column2Exprs(p.Schema().Columns[:oldLen])}.Init(b.ctx, b.getSelectOffset())
          proj.SetChildren(p)
          schema := expression.NewSchema(p.Schema().Clone().Columns[:oldLen]...)
          for _, col := range schema.Columns {
             col.UniqueID = b.ctx.GetSessionVars().AllocPlanColumnID()
          }
          proj.names = p.OutputNames()[:oldLen]
          proj.SetSchema(schema)
          return proj, nil
       }
     
       return p, nil
    }

这段代码非常长，可以看出来构建物理计划的复杂程度，进来先是一些参数获取和声明，不多说，后面开始将AST树的各个节点逐步拆分，并构建计划，首先是判断数据源，也就是From节点，当From节点不为空的时候会进入节点构建查询计划的数据源，当From为空的时候则会使用Dual表来构建查询计划中的数据源（Dual表是一个虚拟表，空表的意思，多用于不需要From 某个表的时候），解析表完成后，下一步展开字段，也就是将查询语句中的 “\*” 展开成表中的字段。

后面就是按照一般的SQL计划构建流程，在代码中我都已经注释上了相关语句的含义，其中要注意的一点是，很多构建会分为两步，先进行解析，解析成Map形式，中间进行一些验证和判断，到后面构建的时候再使用，这个需要重点关注。

代码中有两种类型的注释，一个是英文的，由开发者注释的，这里进行了保留，二中是中文的，我注释的，是为了理解这个过程。一般的SQL解析流程 From → Join → Where → GroupBy → Having → Select → Select Function → Distinct → OrderBy → Limit 和这个方法中的过程基本相同，唯一一个区别是Having字段的构建放到了Select后面。

这段代码主要作用是构建逻辑计划，将一句SQL按照一定的顺序通过AST来一步一步的构建成一个逻辑计划，中间涉及到的步骤非常多，每一步的构建也能展开深入，其实本来准备每一个构建方法都进入去讲解并记录一下，但是这个工作量会非常大，时间有限，所以没有做过多的深入，只是简单的过了一下，后面有机会的话会将这个拆分，每一个都详细的分析。现在可以简单看一下关于解析出来的逻辑计划的结构：

![watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L0NCR0NhbXB1cw_size_16_color_FFFFFF_t_70 4][]

首先可以看出这是一个 LogicalProjection 类型计划，也就是选择型计划，下面分为两个大部分 一个是 logicalSchemaProducer 和 Exprs，logicalSchemaProducer 名字很直接，就是用来生成logicalSchema的，里面存储着Schema的信息，字段的切片，还有基本计划，具体打开可以看到里面还有一个子节点，存储着Where中的条件。第二个部分 Exprs 则是存储的表达式，Select后面的字段和函数等，当前场景下 Exprs 存储的内容和上面 Schema 中 Column 的一样的，大部分简单查询这两者其实都是差不多的，但是也有不同的时候，比如字段中 有 a + b as c 这种 Expr就会是 Function 类型，如下:

![watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L0NCR0NhbXB1cw_size_16_color_FFFFFF_t_70 5][]

大家也可以试试更多语句，研究一下 Plan 的结构利于我们对于制定计划这一块有更深的了解，也会对后面优化有很大的帮助。

获得一个逻辑计划后，按照我们上面的流程，通过一系列的判断后，接下来就是通过plannercore.DoOptimize(ctx, sctx, builder.GetOptFlag(), logic)方法优化成物理计划。进去看一下：

// DoOptimize optimizes a logical plan to a physical plan.
    func DoOptimize(ctx context.Context, sctx sessionctx.Context, flag uint64, logic LogicalPlan) (PhysicalPlan, float64, error) {
       ......
       logic, err := logicalOptimize(ctx, flag, logic)
        
       ...... 
     
       physical, cost, err := physicalOptimize(logic, &planCounter)
        
       ......
    
       finalPlan := postOptimize(sctx, physical)
       return finalPlan, cost, nil
    }

代码很简单，就三步，首先进行逻辑优化，逻辑优化主要是基于规则的优化，简称RBO(rule based optimization)，然后是进行物理优化，物理优化则是为逻辑查询计划中的算计选择某个具体的实现，通过统计信息计算不同方式的代价，选择代价低的方法，这是属于代价的优化 CBO (cost based optimization)。这两部分官方源码阅读文章都有介绍：

[TiDB 源码阅读系列文章（七）基于规则的优化][TiDB]

[TiDB 源码阅读系列文章（八）基于代价的优化][TiDB 1]

在这里我们就不去分析上面讲到的RBO 和 CBO了，内容比较多，官方文档也有较为详细的讲解，后面我可能在学习这一块时单独记录一篇学习笔记。最后就是 postOptimize() 对计划进行些最后的处理，可以跟进看一下：

func postOptimize(sctx sessionctx.Context, plan PhysicalPlan) PhysicalPlan {
       plan = eliminatePhysicalProjection(plan)
       plan = injectExtraProjection(plan)
       plan = eliminateUnionScanAndLock(sctx, plan)
       plan = enableParallelApply(sctx, plan)
       return plan
    }

极度简单的四个方法，名字也取的相当直白，第一个 eliminatePhysicalProjection(plan) 是消除物理计划中多余的投影，在物理优化后才能调用，当从逻辑计划优化到物理计划后，会留下多余的逻辑投影，判断是否能够消除，如果可以，就会将其消除掉。

第二个 injectExtraProjection(plan) 注释解释是将特定运算符的表达式提取到物理投影运算符中，并将投影注入到操作符下面，这样就可以通过及早求值（eager evaluation）来加速运算了。

第三个 eliminateUnionScanAndLock(sctx, plan) 消除联合扫描和锁，同时也会为 PointGet 和 BatchPointGet （前面讲到过快速生成的计划 PointGetPlan）设置锁。最后 enableParallelApply(sctx, plan) 是进行并行应用，这个需要参数设置。

通过了这四个方法处理完成后，一个物理计划就生成了，随后就是执行该物理计划。稍微总结一下，计划制定的整个流程中核心部分就是逻辑计划生成和优化成物理计划，如果要着重研究这一部分的话，那么这两块是重点，其中关于优化部分内容非常多，包括TiDB官方现在也在不断的添加新的优化方式，SQL的优化决定着数据库的查询性能，一个优秀的计划能节约非常多的资源和时间，所以这一块也一直是数据库系统实现的重点，大家如果想成为一名Contributor，从优化这一块下手也是非常好的切入点。

本文仅仅只是走了一遍计划制定的流程，中间的很多地方同样也没有深入进去，因为内容确实比较多，每一块都展开需要花费足够的精力。这篇文章的意义也是将大家带入进来，理解流程和代码分布，让大家快速入手代码，对于深层次的实现，大家可以对自己感兴趣的地方深入，我也会继续学习下去。

附上学习的流程图：

![watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L0NCR0NhbXB1cw_size_16_color_FFFFFF_t_70 6][]

传送门：

[TiDB源码学习笔记：制定计划][TiDB 2]

[TiDB源码学习笔记：Parser模块][TiDB_Parser]

[TiKV源码略读-Config][TiKV_-Config]

[SQL]: https://zhuanlan.zhihu.com/p/305704259
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L0NCR0NhbXB1cw_size_16_color_FFFFFF_t_70]: https://img-blog.csdnimg.cn/20210709140022590.png?x-oss-process=image/watermark,type_ZmFuZ3poZW5naGVpdGk,shadow_10,text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L0NCR0NhbXB1cw==,size_16,color_FFFFFF,t_70
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L0NCR0NhbXB1cw_size_16_color_FFFFFF_t_70 1]: https://img-blog.csdnimg.cn/20210709140047280.png?x-oss-process=image/watermark,type_ZmFuZ3poZW5naGVpdGk,shadow_10,text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L0NCR0NhbXB1cw==,size_16,color_FFFFFF,t_70
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L0NCR0NhbXB1cw_size_16_color_FFFFFF_t_70 2]: https://img-blog.csdnimg.cn/20210709140108886.png?x-oss-process=image/watermark,type_ZmFuZ3poZW5naGVpdGk,shadow_10,text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L0NCR0NhbXB1cw==,size_16,color_FFFFFF,t_70
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L0NCR0NhbXB1cw_size_16_color_FFFFFF_t_70 3]: https://img-blog.csdnimg.cn/20210709140223739.png?x-oss-process=image/watermark,type_ZmFuZ3poZW5naGVpdGk,shadow_10,text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L0NCR0NhbXB1cw==,size_16,color_FFFFFF,t_70
[TiDB _Cascades Planner]: https://zhuanlan.zhihu.com/p/94079481
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L0NCR0NhbXB1cw_size_16_color_FFFFFF_t_70 4]: https://img-blog.csdnimg.cn/20210709140550301.png?x-oss-process=image/watermark,type_ZmFuZ3poZW5naGVpdGk,shadow_10,text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L0NCR0NhbXB1cw==,size_16,color_FFFFFF,t_70
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L0NCR0NhbXB1cw_size_16_color_FFFFFF_t_70 5]: https://img-blog.csdnimg.cn/20210709140618878.png?x-oss-process=image/watermark,type_ZmFuZ3poZW5naGVpdGk,shadow_10,text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L0NCR0NhbXB1cw==,size_16,color_FFFFFF,t_70
[TiDB]: https://pingcap.com/blog-cn/tidb-source-code-reading-7/
[TiDB 1]: https://pingcap.com/blog-cn/tidb-source-code-reading-8/
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L0NCR0NhbXB1cw_size_16_color_FFFFFF_t_70 6]: https://img-blog.csdnimg.cn/20210709140857732.png?x-oss-process=image/watermark,type_ZmFuZ3poZW5naGVpdGk,shadow_10,text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L0NCR0NhbXB1cw==,size_16,color_FFFFFF,t_70
[TiDB 2]: https://zhuanlan.zhihu.com/p/334642671
[TiDB_Parser]: https://zhuanlan.zhihu.com/p/321360679
[TiKV_-Config]: https://zhuanlan.zhihu.com/p/322400326