SQL 调优能够直接体现在业务的上层应用中，通过 SQL 调优让系统更省资源、执行速度更快，业务效率也会有明显提升。这也是 DBA 工作比较有成就感的一个领域。
OceanBase 的 SQL 和集中式数据库的 SQL 在调优上有很多相似之处，但也有一些是分布式数据库独有的，如负载均衡等。在这之前，我们先回顾一下 SQL 请求处理的流程。
SQL 的解析到执行一共分为六步，如下图所示：
Parser 词法/语法解析
OceanBase 的词法分析使用了 LEX 分析器，语法分析用了 YCC 分析器。在收到用户发送的 SQL 请求串后，Parser 会将字符串分成一个个的“单词”，并根据预先设定好的语法规则解析整个请求，将 SQL 请求字符串转换成带有语法结构信息的内存数据结构，我们称为“语法树”（Syntax Tree） 。为了加速 SQL 请求的处理速度，OceanBase 对 SQL 请求采用了特有的“快速参数化”，以加速查找 plan cache 的速度。
Resolver 语义解析
当 SQL 请求字符串经过语法、词法解析，生成“语法树”之后， resolver 会进一步将该语法树转换为带有数据库语义信息的内部数据结构。在这一过程中，resolver 将根据数据库元信息将 SQL 请求中的 token 翻译成对应的对象（例如库、表、列、索引等），生成的数据结构叫做 Statement Tree（语句树）。
Transformer 逻辑改写
OceanBase 基于逻辑改写有两个引擎，即基于规则的重写和基于代价的重写。系统会先执行基于规则的重写，再根据基于代价的重写判断。这是一个持续迭代的过程，即先通过规则做处理，再根据代价做判断，然后又返回去做规则的重写。
基于规则的重写主要处理内连接的消除、视图的合并、外连接的消除等。基于代价的重写主要处理每一个执行计划需要多少 cost，并比较所有 cost 来找到一条最小 cost，这个过程需要优化器一起参与。
Optimizer 优化器
优化器是整个 SQL 请求优化的核心，其作用是为 SQL 请求生成最佳的执行计划。优化器是通过自底向上分析表访问路径连接算法以及物理对象的分布。在优化过程中，优化器需要综合考虑 SQL 请求的语义、对象数据特征、对象物理分布等多方面因素，解决访问路径选择、连接顺序选择、连接算法选择、分布式计划生成等多个核心问题，最终选择一个对应该 SQL 的最佳执行计划。
Code Generator 代码生成器
优化器负责生成最佳的执行计划，但其输出的结果并不能立即执行，还需要通过代码生成器将其转换为可执行的代码，这个过程由 Code Generator 负责。Code Generator 执行的过程只是忠实地将优化器的生成结果翻译成可执行代码，并不做任何优化选择。
Executor 执行器
对于本地执行作业，Executor 会简单的从执行计划顶端的算子开始调用，由算子自身的逻辑完成整个执行的过程，并返回执行结果。对于远程或分布式作业，Executor 需要根据预选的划分，将执行树分成多个可以调度的 job，并通过 RPC 将其发送给相关的节点执行。
Plan Cache 执行计划缓存
由于一个 SQL 在这六个步骤的执行过程中，对系统的消耗比较大，尤其是在 OLTP 场景中，这个耗时往往不可忽略。因此SQL 执行引擎会将 SQL 第一次生成的执行计划缓存在内存中，后续对该 SQL 的重复执行可以复用这个计划，避免了重复查询优化的过程。
有了执行计划缓存，Resolver、Transformer、Optimizer和Code Generator这四步都会省掉。对 OceanBase 数据库来说，只需要在第一步命中计划缓冲，直接就进入执行的步骤。
计划缓存是 OceanBase 的 KV cache 里的一块内存区域。这块内存区域默认情况下占用了租户的 5%，具体也可以自行配置，比如高水位线、低水位线的刷新等。
