TiDB源码学习笔记：执行计划

爱被打了一巴掌 2023-10-03 10:26 11阅读 0赞

> TiDB源码研究系列第五篇，从一句SQL出发，在SQL计划制定之后继续研究执行计划。

在前面的文章中，我跟踪了SQL的解析，逻辑计划制定，计划优化（只提到过）和物理计划制定后，接下来就是要去执行计划了，在TiDB中执行计划大致可以分为以下几个部分：

1.  需要构造执行器去执行该计划，对于不同的语句类型，执行器的类型也会不同
2.  在执行计划中验证事务，对于一个事务，在执行的过程中，保证其事务性，需要不断的验证事务，中间如果有失败需要回滚
3.  与TiKV的交互，TiDB中执行计划的最终结果是由TiKV提供
4.  与客户端交互，查询数据时需要将数据写回客户端

还是以跟踪代码的方式，逐步经过执行计划的流程，了解下代码逻辑，以SQL：”select \* from student where name='jk'“为例。

注意了，前面也说到过，一个数据库系统十分复杂，每一类查询语句都有不同的处理方式，我们这里只选择了一句非常简单的 Select 语句作为例子，目的时为了去初步了解代码架构，对于复杂的语句和不同类型的语句，查询过程也会不一样，大家要想了解需要自己跟踪了。  
进入源码之前，我们可以回顾下 [TiDB源码阅读 3：SQL的一生][TiDB_ 3_SQL]，再熟悉下SQL的整个处理流程，然后锁定执行计划这一块，有一个整体的框架，再去逐步细分中间过程，那么理解起来会更容易，进入源码后，也能更快找到关键的方法和步骤。  
好了，进入源码，直接跳到 session/session.go 下的 ExecuteStmt() 方法，这个方法应该很熟悉了，在前面提到过很多次了，里面包括了事务准备，抽象语法树解析为物理计划和执行计划，重点包括执行计划。简单看一下:

**ExecuteStmt**

func (s *session) ExecuteStmt(ctx context.Context, stmtNode ast.StmtNode) (sqlexec.RecordSet, error) {
    
     ...... 
    
    // Transform abstract syntax tree to a physical plan(stored in executor.ExecStmt).  
    
    compiler := executor.Compiler{Ctx: s} 
    
    stmt, err := compiler.Compile(ctx, stmtNode) 
    
    ......
    
     // Execute the physical plan.  
    
    logStmt(stmt, s.sessionVars) recordSet, err := runStmt(ctx, s, stmt)
    
     ...... 
    }

上面的一步 Compile() 在 [TiDB源码学习笔记：制定计划][TiDB] 中重点跟入过，就不多讲，现在需要跟踪就是 runStmt() 这个方法，注释也非常直白执行物理计划。

**runStmt**

// runStmt executes the sqlexec.Statement and commit or rollback the current transaction.
    func runStmt(ctx context.Context, se *session, s sqlexec.Statement) (rs sqlexec.RecordSet, err error) {
       ......
    
       sessVars := se.sessionVars
       // Save origTxnCtx here to avoid it reset in the transaction retry.
       origTxnCtx := sessVars.TxnCtx
       err = se.checkTxnAborted(s)
    
       ......
    
       // 执行物理计划
       rs, err = s.Exec(ctx)
       // 记录执行计划的语句数量
       sessVars.TxnCtx.StatementCount++
        
       // 如果不是只读操作，则需要验证事务，进行提交事务或者回滚事务
       if !s.IsReadOnly(sessVars) {
          // All the history should be added here.
          if err == nil && sessVars.TxnCtx.CouldRetry {
             GetHistory(se).Add(s, sessVars.StmtCtx)
          }
    
          // Handle the stmt commit/rollback.
          if se.txn.Valid() {
             if err != nil {
                se.StmtRollback()
             } else {
                se.StmtCommit()
             }
          }
          err = finishStmt(ctx, se, err, s)
       }
    
       // 当存在返回值的时候，返回结果集。
       if rs != nil {
          return &execStmtResult{
             RecordSet: rs,
             sql:       s,
             se:        se,
          }, err
       }
    
       // 判断是否为特殊语句
       if se.hasQuerySpecial() {
          // The special query will be handled later in handleQuerySpecial,
          // then should call the ExecStmt.FinishExecuteStmt to finish this statement.
          se.SetValue(ExecStmtVarKey, s.(*executor.ExecStmt))
       } else {
          // If it is not a select statement or special query, we record its slow log here,
          // then it could include the transaction commit time.
          s.(*executor.ExecStmt).FinishExecuteStmt(origTxnCtx.StartTS, err == nil, false)
       }
       return nil, err
    }

代码比较简单，我也增加了一些注释，加上原有注释就比较好理解了，先回保存当前事务信息，用于重置时可以直接使用，然后执行物理计划，判断计划是否为只读计划，这个地方只读代表的就是 Select 之类，如果不是只读，那么意味着有数据修改等操作，则需要验证事务，来判断是提交还是回滚，最后完成语句。那么如果语句有返回值，则直接返回结果集。  
这个地方可能有些疑惑，涉及到TiDB的分布式事务，需要了解一个MVCC的设计。官方介绍：

[TiKV 的 MVCC（Multi-Version Concurrency Control）机制][TiKV _ MVCC_Multi-Version Concurrency Control]

在这里我说一下我的理解，MVCC是一个并多版本的并发控制，什么意思，就是将修改数据的操作，类似 update 这类操作，加上一个版本号，修改前的数据版本号为 1.0， 修改一次后，不删除 1.0 版本，新增加一个 1.1 的版本。那么在大量读的场景下时，每一次读，给读操作一个版本号，如果读操作的版本号为 1.0 ，那么他读的就是 1.0 版本的数据，如果读操作是 1.1 的版本号，那么读到的数据就是 1.1 版本的数据，这样的情况下，我们在只读操作的时候就不需要对数据上锁，极大的节省了时间，提高了效率。所以对于读和写两种操作时，TiDB的处理方式是不一样的。当然这种方式会出现一定的问题，write skew（偏序），因为这个原因，TiDB隔离级别只能达到SI，而达不到SSI（隔离级别可以百度查一下），我相信后期会有所优化，达到SSI的隔离级别。 回到代码，因为我们的SQL是纯 Select 形式，所以不会进行事务验证，提交还是回滚等判断，直接就是返回一个结果集，所以其他的先不做深入研究，那么这一段里面我们继续跟进到执行物理计划这个方法 s.Exec(ctx)：

**Exec**

// Exec builds an Executor from a plan. If the Executor doesn't return result,
    // like the INSERT, UPDATE statements, it executes in this function, if the Executor returns
    // result, execution is done after this function returns, in the returned sqlexec.RecordSet Next method.
    func (a *ExecStmt) Exec(ctx context.Context) (_ sqlexec.RecordSet, err error) {
       ......
    
       // 构建执行器
       e, err := a.buildExecutor()
       if err != nil {
          return nil, err
       }
    
       // 根据不同执行者进行不同的处理
       if err = e.Open(ctx); err != nil {
          terror.Call(e.Close)
          return nil, err
       }
       ......  
    
       return &recordSet{
          executor:   e,
          stmt:       a,
          txnStartTS: txnStartTS,
       }, nil
    }

如果大家还有印象的话，在 SQL的一生中 我讲到过这个方法，但是只是简单过了一下，现在我们需要深入 buildExecutor() 和 Open() 这两个方法中，前一个方法是构建一个执行者，很好理解，后一个方法Open()，在我之前的笔记中记录的是初始化构建者的参数，这只是 TableReaderExecutor 执行者的 Open() 实现，对于不同的执行者 Open() 是不一样，这个地方是我大意了啊。 后面我又研究了一下关于 Executor 的接口：

// Executor is the physical implementation of a algebra operator.
    //
    // In TiDB, all algebra operators are implemented as iterators, i.e., they
    // support a simple Open-Next-Close protocol. See this paper for more details:
    //
    // "Volcano-An Extensible and Parallel Query Evaluation System"
    //
    // Different from Volcano's execution model, a "Next" function call in TiDB will
    // return a batch of rows, other than a single row in Volcano.
    // NOTE: Executors must call "chk.Reset()" before appending their results to it.
    type Executor interface {
       base() *baseExecutor
       Open(context.Context) error
       Next(ctx context.Context, req *chunk.Chunk) error
       Close() error
       Schema() *expression.Schema
    }

大家可以看一下这篇论文："Volcano-An Extensible and Parallel Query Evaluation System"（对于新手来说，想要进入到数据库底层的学习，确实是太难了）

火山模型其实是一个非常经典的SQL计算模型，像Oracle和MySQL等数据库也是基于火山模型的SQL处理，火山模型也叫迭代模型，首先看一下我们前面的计划制定，还有抽象语法树，都是以树的结构来记录数据，那么迭代模型其实也类似，我们的执行者也是一个有向无环图（大多数就是一棵树，简单理解），其中每个节点，就是一个算子，它实现了三个方法，Open()，Next()，Close()，每个方法中都会调用自己子节点的该方法，同时进行其他一些处理，那么一直调用下去就会直到叶子节点，遍历完所有节点并进行了相关操作。其中Next()是调用子节点的next()并且完成自己的计算逻辑，获取数据，根节点调用一次，就能将所有节点数据取到，后面的open()，close()也类似，open()是进行该节点初始化操作并且调用子节点的open()，close()则是清理该节点并调用子节点close()。  
其实我们在这里简单理解下就行，然后跟着代码走走，依靠代码领悟一下就好了，首先我们跟进 buildExecutor() 这个方法，来构造一个执行器。

**buildExecutor**

// buildExecutor build a executor from plan, prepared statement may need additional procedure.
    func (a *ExecStmt) buildExecutor() (Executor, error) {
       ctx := a.Ctx
       stmtCtx := ctx.GetSessionVars().StmtCtx
       
       // 判断计划类型如果不是 Execute，则进行一些参数控制
       if _, ok := a.Plan.(*plannercore.Execute); !ok {
          ......
       }
       
       // 判断计划类型是否为分析并在受限SQL中，进行些参数控制
       if _, ok := a.Plan.(*plannercore.Analyze); ok && ctx.GetSessionVars().InRestrictedSQL {
          ......
       }
    
       // 新建一个构造者
       b := newExecutorBuilder(ctx, a.InfoSchema)
       e := b.build(a.Plan)
       if b.err != nil {
          return nil, errors.Trace(b.err)
       }
    
       // ExecuteExec is not a real Executor, we only use it to build another Executor from a prepared statement.
       if executorExec, ok := e.(*ExecuteExec); ok {
          ......
       }
      
       a.isSelectForUpdate = b.hasLock && (!stmtCtx.InDeleteStmt && !stmtCtx.InUpdateStmt && !stmtCtx.InInsertStmt)
       return e, nil
    }

代码进行了一定的简化，可以看到，对于不同的计划类型增加一些额外的参数控制，来进行查询的优化和不同的策略，代码中都进行了一定的注释，其中重点还是在与 newExecutorBuilder() 和 b.build() 这两段代码中，newExecutorBuilder() 方法比较简单，新建一个对象，在build进行初始化，并返回一个构建者，里面代码逻辑也比较简单：

**build**

func (b *executorBuilder) build(p plannercore.Plan) Executor {
       switch v := p.(type) {
       .......
    
       case *plannercore.PhysicalTableReader:
          return b.buildTableReader(v)
    
       .......
       default:
          if mp, ok := p.(MockPhysicalPlan); ok {
             return mp.GetExecutor()
          }
    
          b.err = ErrUnknownPlan.GenWithStack("Unknown Plan %T", p)
          return nil
       }
    }

判断计划的类型，根据不同类型的计划构建不同的执行者，这个地方现在一共有66种计划，非常多，后期可能会根据语法支持和特性支持的增加，而增加更多的计划。对于当前的SQL语句 ”Select \* from student where name='jk'“来说，在上一章笔记制定计划中，知道其计划类型为 PhysicalTableReader， 所有在这里会 buildTableReader 构建一个读表执行者（其他的计划类型我们暂且就不去跟踪了）。

**buildTableReader**

// buildTableReader builds a table reader executor. It first build a no range table reader,
    // and then update it ranges from table scan plan.
    func (b *executorBuilder) buildTableReader(v *plannercore.PhysicalTableReader) Executor {
       // 判断是否为读一致性的悲观事务
       // 隔离等级为IS， 且为悲观事务
       if b.ctx.GetSessionVars().IsPessimisticReadConsistency() {
          if err := b.refreshForUpdateTSForRC(); err != nil {
             b.err = err
             return nil
          }
       }
       
       // 使用MPP构建执行者
       // 只有在广播模式下才进行
       if useMPPExecution(b.ctx, v) {
          return b.buildMPPGather(v)
       }
       
       // 先构建一个无范围的表读
       ret, err := buildNoRangeTableReader(b, v)
       if err != nil {
          b.err = err
          return nil
       }
    
       // 通过表扫描计划来更新读表范围
       ts := v.GetTableScan()
       ret.ranges = ts.Ranges
       sctx := b.ctx.GetSessionVars().StmtCtx
       sctx.TableIDs = append(sctx.TableIDs, ts.Table.ID)
    
       // 如果不使用动态分区进行修建则直接返回
       if !b.ctx.GetSessionVars().UseDynamicPartitionPrune() {
          return ret
       }
    
       // 否则获取分区信息
       pi := ts.Table.GetPartitionInfo()
       if pi == nil {
          return ret
       }
       
       // 动态分区修剪
       tmp, _ := b.is.TableByID(ts.Table.ID)
       tbl := tmp.(table.PartitionedTable)
       partitions, err := partitionPruning(b.ctx, tbl, v.PartitionInfo.PruningConds, v.PartitionInfo.PartitionNames, v.PartitionInfo.Columns, v.PartitionInfo.ColumnNames)
       if err != nil {
          b.err = err
          return nil
       }
       
       // 如果存储引擎时TiFlash则进行其他处理
       // TiFlash 为列存 与 TiKV 存储方式不一样，处理方式不同，这里先不考虑
       if v.StoreType == kv.TiFlash {
         ......
       }
    
       // 修剪后发现分区为空则返回一个Dual表执行者
       if len(partitions) == 0 {
          return &TableDualExec{baseExecutor: *ret.base()}
       }
      
       // 在执行者中增加数据读取的 KV范围
       ret.kvRangeBuilder = kvRangeBuilderFromRangeAndPartition{
          sctx:       b.ctx,
          partitions: partitions,
          ranges:     ts.Ranges,
       }
    
       return ret
    }

这个过程在代码中已经添加了注释，但还是要稍微解释下，方法进来首先判断读的形式，是否为读一致性，且为悲观事务，读一致性涉及到数据库的隔离等级，前面其实讲到过，TiBD的隔离等级达到SI(快照隔离)，满足读一致性，就是说在一个事务中，前后两次读到的数据要保持一致，即使中间有其他事务提交了数据的修改。简单举个例子，事务A 读取了一个数据 X = 0， 十分钟后又读了一次X（这里把时间放大了），但是在两次读中间，五分钟的时候事务B修改了X = 1，那么再过五分钟，事务A回去读 X 还是为 0，就满足了读一致性。  
再讲讲悲观事务，也很简单，在并发中，悲观事务是在提交事务前，拿到数据的时候立马加锁，不让别人动，因为大家都会来和我抢数据，这样在提交事务的时候，确保事务一定成功，反之，乐观事务，就是大家都不会来跟我抢，所以我直到提交事务的时候才去校验能否成功，不成功则事务失败，回滚重试或者报个错。那么一般在TiDB 中都默认的乐观事务，3.0.8版本后可以修改参数设定悲观事务，两者各有各的好处，悲观事务会有大量等锁的情况发生，而乐观事务会出现事务失败重试的情况，根据我们查询的场景不同，可以采用不同的模式。  
然后就是MPP执行，MPP又是一个大规模并行的架构，这里就不讲解了，大家有兴趣可以百度，TiDB中使用的情况较少。  
继续往下会进行一个无范围的读表构建，然后通过前面制定计划中的扫描条件，不断的缩小范围，确定最终的扫描范围。  
最后就是一个关于分区的修剪了，在我们当前这个情景下是用不到分区的，因为数据非常少，也没有多个存储节点。分区表其实非常好理解，就是将一张大表，根据一定的规则，可以是字段，分成很多个小表，放在不同的节点上（分区上），逻辑上我们使用时还是一张表，物理上其实分多个节点存储。那么这样有什么好处呢？其实在大多数的查询中都不会全表查询，而是有一定的限制条件，比如某某年份，如果将一张表按照年份字段进行分区，那么查询的时候，如果我只查询部分年份的数据，就只用访问一个分区上的数据，这样会加快查询的性能，同时某个分区出现问题的时候，其他分区也还是能正常运行。分区这里也不做过多的深入，大家可以自己多了解下。  
回到上上层，也就是构建完成执行者后，接下来便是执行任务，也就是 Exec 中的 Open 方法，那么当前的SQL语句场景下的 open 方法则是基于 TableReaderExecutor 的实现

**Open**

// Open initialzes necessary variables for using this executor.
    func (e *TableReaderExecutor) Open(ctx context.Context) error {
       ......
    
       var err error
       // 判断 Filter 中是否有关联列条件
       // 如果有则构建DAG树中的节点，部分节点可以进行下推，下推到TiKV中执行
       if e.corColInFilter {
          if e.storeType == kv.TiFlash {
             execs, _, err := constructDistExecForTiFlash(e.ctx, e.tablePlan)
             if err != nil {
                return err
             }
             e.dagPB.RootExecutor = execs[0]
          } else {
             e.dagPB.Executors, _, err = constructDistExec(e.ctx, e.plans)
             if err != nil {
                return err
             }
          }
       }
       // 运行时状态信息统计，不为空的时候开启执行摘要的收集
       if e.runtimeStats != nil {
          collExec := true
          e.dagPB.CollectExecutionSummaries = &collExec
       }
       
       // 判断 Access 中是否有关联列条件
       // 存在处理关联条件，重新划分查询范围
       if e.corColInAccess {
          ts := e.plans[0].(*plannercore.PhysicalTableScan)
          access := ts.AccessCondition
          pkTP := ts.Table.GetPkColInfo().FieldType
          e.ranges, err = ranger.BuildTableRange(access, e.ctx.GetSessionVars().StmtCtx, &pkTP)
          if err != nil {
             return err
          }
       }
       ......
    
       // 当主键为无符号时，会将 Ranges 划分为 signedRanges 和 unsignedRanges 两部分分别请求处理
       // 当ranges中的 HighVal > MaxInt64 时 划分为 unsignedRanges 
       // 另外的一部分划分为 signedRanges
       // 当不需要需要排序时，将 signedRanges ，unsignedRanges 都作为 firstPartRanges 返回，secondPartRanges 为nil
       // 当需要排序时，如果为升序，则 signedRanges 作为 firstPartRanges, unsignedRanges 作为 secondPartRanges 返回
       // 如果为降序，则 unsignedRanges 作为 firstPartRanges， signedRanges 作为 secondPartRanges  返回
       firstPartRanges, secondPartRanges := splitRanges(e.ranges, e.keepOrder, e.desc)
      
       // 将 firstPartRanges 进行执行，请求TiKV并获取返回的结果
       firstResult, err := e.buildResp(ctx, firstPartRanges)
       if err != nil {
          e.feedback.Invalidate()
          return err
       }
    
       // 当 secondPartRanges 没有时，直接将第一部分结果进行整合
       if len(secondPartRanges) == 0 {
          e.resultHandler.open(nil, firstResult)
          return nil
       }
    
       // 当 secondPartRanges 存在值时，请求TiKV并获取返回的结果
       var secondResult distsql.SelectResult
       secondResult, err = e.buildResp(ctx, secondPartRanges)
       if err != nil {
          e.feedback.Invalidate()
          return err
       }
       // 将两部分的结果进行整合
       e.resultHandler.open(firstResult, secondResult)
       return nil
    }

这段代码比较难理解，即使我现在也不是完全懂它的含义，借助注释和代码逻辑，能够推断出，这一段代码时进行请求构建，发送到TiKV，然后整合结果。其中主要需要理解的是 Ranges 的含义，从头到尾都是对 Ranges 的处理。  
前面讲到过 TiDB 是 KV 存储，所有数据就是一个Map，通过 Key 获取 Value，并且 TiDB 是范围分区，也就是数据是 \[Key\_1, Key\_2 ......Key\_n\]，\[Key \_n, Key\_n+1....... Key\_n+n\]，....... 的存储形式，一张表的 RowId 都在一个 \[0，MaxInt64) 的范围内，那么在读取数据的时候，构造一个 \[starKey, endKey) 的范围，就能读到这个范围内的所有数据了。可以参考下面文章文章。

[三篇文章了解 TiDB 技术内幕 - 说计算][TiDB _ -]

这段代码主要就是构造这个 Ranges 并发送请求获取数据，但是代码并没有那么简单，因为这个中间还会进行一定的优化，比如算子下推，还有相关列的处理，说到相关列，这里有个小细节，就是 Access 和 Filter的区别，其实一开始我也不懂，后面查了一下，Access 表示谓词条件代表存在索引，也就是查表的时候是按照索引查询还是直接表查询，Fileter就是普通的过滤数据的作用。  
最后有一段代码是将 Ranges 分为 firstPartRanges 和 secondPartRanges 然后分别发请求获取数据最后再整合，这一段可能看的比较懵，注释也不是很全，花费了我一段时间研究，方法上加上了注释，splitRanges 通过 主键类型，是否排序，排序类型来划分为两个部分来请求数据，再后面的 e.resultHandler.open() 中 对着两部分进行处理，可以看一下代码在这一块的注释：

type tableResultHandler struct {
       // If the pk is unsigned and we have KeepOrder=true and want ascending order,
       // `optionalResult` will handles the request whose range is in signed int range, and
       // `result` will handle the request whose range is exceed signed int range.
       // If we want descending order, `optionalResult` will handles the request whose range is exceed signed, and
       // the `result` will handle the request whose range is in signed.
       // Otherwise, we just set `optionalFinished` true and the `result` handles the whole ranges.
       optionalResult distsql.SelectResult
       result         distsql.SelectResult
    
       optionalFinished bool
    }

大概意思和我前面的代码注释意思差不多，最后整合结果时通过 optionalResult 和 result 来处理 firstPartRange 和 secondPartRanges 的请求结果，发送请求的方法是 buildResp，我们可以跟进看一下

**buildResp**

// buildResp first builds request and sends it to tikv using distsql.Select. It uses SelectResut returned by the callee
    // to fetch all results.
    func (e *TableReaderExecutor) buildResp(ctx context.Context, ranges []*ranger.Range) (distsql.SelectResult, error) {
       var builder distsql.RequestBuilder
       var reqBuilder *distsql.RequestBuilder
    
    
       // 如果本来就存在 KvRangeBuild 的话 就直接用其获取 KeyRange，然后构建请求 
       if e.kvRangeBuilder != nil {
          kvRange, err := e.kvRangeBuilder.buildKeyRange(getPhysicalTableID(e.table))
          if err != nil {
             return nil, err
          }
          reqBuilder = builder.SetKeyRanges(kvRange)
       } else if e.table.Meta() != nil && e.table.Meta().IsCommonHandle {
          // 通过公共句柄构建请求
          reqBuilder = builder.SetCommonHandleRanges(e.ctx.GetSessionVars().StmtCtx, getPhysicalTableID(e.table), ranges)
       } else {
          // 通过表范围构建请求
          reqBuilder = builder.SetTableRanges(getPhysicalTableID(e.table), ranges, e.feedback)
       }
       // 构建kv请求
       kvReq, err := reqBuilder.
          SetDAGRequest(e.dagPB).
          SetStartTS(e.startTS).
          SetDesc(e.desc).
          SetKeepOrder(e.keepOrder).
          SetStreaming(e.streaming).
          SetFromSessionVars(e.ctx.GetSessionVars()).
          SetMemTracker(e.memTracker).
          SetStoreType(e.storeType).
          SetAllowBatchCop(e.batchCop).
          Build()
       if err != nil {
          return nil, err
       }
       e.kvRanges = append(e.kvRanges, kvReq.KeyRanges...)
       
       // 发送请求获取结果
       result, err := e.SelectResult(ctx, e.ctx, kvReq, retTypes(e), e.feedback, getPhysicalPlanIDs(e.plans), e.id)
       if err != nil {
          return nil, err
       }
       result.Fetch(ctx)
       return result, nil
    }

这个方法就相对简单许多，不用太多的解释和思考，基本就是通过前面执行者的参数和 Ranges 来构建请求的 kvReq，然后便是发送请求到 TiKV 获取数据，当然这个 buildResp 也是基于 TableReaderExecutor 的实现，不同的查询类型实现也是不一样的，顺带提一下，这个地方发送请求是通过 distsql 中的 Select 去发送的 DAG 请求，主要参数还是 KvReq 和 KvRanges，其他的参数可选，对于 distsql 这个包，专门负责 TiKV 的交互，大家有兴趣可以深入了解下。  
读写请求是不一样的，写请求的话是没有数据返回的，但是读数据会有大量数据返回，而且数据是从不同的 Region 中获取到的，所以 TiDB 将获取到数据都会写入到 Chunk 中，这也是 TiDB 中的一个概念，在SQL的一生中我们曾讲到过这一块，在写入客户端的时候，就会调用结果集 ResultSet 中的 Next 方法去读取数据，Next方法中就会不断的遍历 nextChunk 来获取 Chunk 中的数据，最后写入到客户端，就完成了一次查询。  
到这里 ”Select \* from student where name = 'jk'“这句查询也就结束了，这是一句很简单的查询，中间没有涉及到联表，聚合，索引等等，但是整个过程中还是有很多地方难到了我，对于许多地方也是学的一知半解，毕竟回到最初说的，一个数据库系统的实现是非常复杂的，一个分布式关系型数据库会更复杂点，所以想要完全去掌握，吃透还是要费很长时间的。  
大概学习了有一个月了，一个SQL层的流程只能说是初步掌握，刚刚入门，后面的路还很长，但也会一直坚持对于数据库底层这一块的学习，当然也会不断的记录学习的笔记，其实记录笔记真的是一件非常好的习惯，虽然笔记写的坑坑洼洼的比较难看，但是每次写笔记都能重新梳理一遍知识点，反复咀嚼，慢慢有很多东西都会有新的理解，同时能帮助到其他人的学习也是非常好的。  
最后附上简单的流程图：

![watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L0NCR0NhbXB1cw_size_16_color_FFFFFF_t_70][]

**传送门**

**[TiDB源码学习笔记：执行计划][TiDB 1]**

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

**[使用AWS Devops工具结合ECS实现自动化Docker容器部署][AWS Devops_ECS_Docker]**

[TiDB_ 3_SQL]: https://link.zhihu.com/?target=https%3A//confluence.digitalchina.com/pages/viewpage.action%3FpageId%3D9321694
[TiDB]: https://zhuanlan.zhihu.com/p/334642671
[TiKV _ MVCC_Multi-Version Concurrency Control]: https://pingcap.com/blog-cn/mvcc-in-tikv/
[TiDB _ -]: https://pingcap.com/blog-cn/tidb-internal-2/
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L0NCR0NhbXB1cw_size_16_color_FFFFFF_t_70]: https://img-blog.csdnimg.cn/20210709142617637.png?x-oss-process=image/watermark,type_ZmFuZ3poZW5naGVpdGk,shadow_10,text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L0NCR0NhbXB1cw==,size_16,color_FFFFFF,t_70
[TiDB 1]: https://zhuanlan.zhihu.com/p/337939383
[TiKV_-Config TiKV_-Config]: https://zhuanlan.zhihu.com/p/322400326
[AWS Devops_ECS_Docker]: https://zhuanlan.zhihu.com/p/334991899