vlambda博客
学习文章列表

TiDB Server数据库优化器主要是通过pre process、Logical Optimize、Physical Optimize模块来进行优化SQL，使SQL语句选择最优的执行计划进行数据读取。

架构图

• Protocol Layer：客户端发起链接请求后，首先来到Protocol Layer，这里是与Client交互的接口，主要负责管理客户端链接、解析MySQL命令并返回执行结果。

• Parse：解析完毕后进行Parse模块，Parse主要作用是校验SQL语法正确性(语法分析)、SQL解析为AST语法树。

• pre process（预处理优化）：针对点查进行优化（走主键索引或者唯一索引的查询），如果过滤查询为等值的单表的SELECT/UPDATE/DELETE操作，则会跳过Logical Optimize和Physical Optimize，下推到Distributed Coprocessor。

• Logical Optimize（逻辑优化）：表是否存在、是否有表的权限，对SQL语句进行优化：子查询、分区裁剪、聚合消除、MAX/MIN优化、投影消除、外连接消除、谓词下推（将过滤规则下推到各个存储节点，尽可能将计算下推到存储节点进行计算）、连接顺序调整（多表查询中，根据表连接条件和数量进行调整，找到最优的过滤方式），并生成逻辑执行计划。

• Physical Optimize（物理优化）：根据逻辑优化的结果和表的统计信息，决定最终的扫描方式、索引选择和算子，你要取的数据怎么获取比较好，选择最优路径选择，最终会生成执行计划。在物理优化层面，需要根据统计信息来产生执行计划。

• TiDB Executor（执行器）：最底层的Executor会根据这条SQL处理的Key范围，构建出多个要下发到TiKV的请求，并通过distsql的API将这些请求分发到TiKV。

• Distributed Coprocessor：分布式计算将该应用分解成许多小的部分，分配给多台计算机进行处理。这样可以节约整体计算时间，大大提高计算效率。

pre process（预处理优化）

Logical Optimize（逻辑优化）

Physical Optimize（物理优化）