在开始介绍如何优化SQL语句前 ，先来了解一下OceanBase的SQL执行流程
SQL 发送到 OBServer 后，会先由 OBServer 对其进行快速参数化，参数化后的 SQL 进入 Plan Cache 尝试命中计划缓存。
如果找到一个可以使用的计划，则直接将计划交由 SQL 的执行引擎去执行，并将执行完成后的结果返回给用户；如果没有找到可以使用的计划，则会重新为此 SQL 生成计划，完整地执行 SQL 的 Parser、Resolver、Transformer、Optimizer、Code Generator 流程，然后生成一个可用的物理计划，并交由执行引擎执行，同时此计划会被加入到计划缓存，以便后续的 SQL 重新使用。
SQL请求执行流程
Parser（词法/语法解析模块）
在收到用户发送的SQL请求串后，Parser会将字符串分成一个个的“单词”，并根据预先设定好的语法规则解析整个请求，将SQL请求字符串转换成带有语法结构信息的内存数据结构，我们称为“语法树”（Syntax Tree），如下图所示，它将用户的 SQL 拆成了一个树状结构，同时做了一些语法解析。使用 OceanBase 时候的语法报错通常就是在 Parser层。
为了加速SQL请求的处理速度，OceanBase对SQL请求采用了特有的“快速参数化”，以加速查找plan cache的速度。
Resolver（语义解析模块）
当SQL请求字符串经过语法、词法解析，生成“语法树”之后，resolver会进一步将该语法树转换为带有数据库语义信息的内部数据结构。
在这一过程中，resolver将根据数据库元信息将SQL请求中的token翻译成对应的对象（例如库、表、列、索引等），生成的数据结构叫做Statement Tree。
Transformer（逻辑改写模块）
在查询优化中，经常利用等价改写的方式，将用户SQL转换为与之等价的另一条SQL，以便于优化器为之生成最佳的执行计划，我们称这一过程为“查询改写”。
Transformer在resolver之后，分析用户SQL的语义，并根据内部的规则或代价模型，将用户SQL“改写”为与之等价的其他形式，并将其提供给后续的优化器做进一步的优化。
Optimizer（优化器）
优化器是整个SQL请求优化的核心，其作用是为SQL请求生成最佳的执行计划。
在优化过程中，优化器需要综合考虑SQL请求的语义、对象数据特征、对象物理分布等多方面因素，解决访问路径选择、连接顺序选择、连接算法选择、分布式计划生成等多个核心问题，最终选择一个对应该SQL的最佳执行计划。
为了充分利用OceanBase的分布式架构和多核计算资源的优势，OceanBase的查询优化器会对执行计划做并行优化：根据计划树上各个节点的数据分布，对串行执行计划进行自底向上的分析，把串行的逻辑执行计划改造成一个可以并行执行的逻辑计划。
Code Generator（代码生成器）
优化器负责生成最佳的执行计划，但其输出的结果并不能立即执行，还需要通过代码生成器将其转换为可执行的代码，这个过程由Code Generator负责。
Code Generator执行的过程只是忠实地将优化器的生成结果翻译成可执行代码，并不做任何优化选择。
Executor（执行器）
对于本地执行作业，Executor会简单的从执行计划的顶端的算子开始调用，由算子自身的逻辑完成整个执行的过程，并返回执行结果。
对于远程或分布式作业，Executor需要根据预选的划分，将执行树分成多个可以调度的Job，并通过RPC将其发送给相关的节点执行。
Plan Cache（执行计划缓存模块）
执行计划的生成是一个比较复杂的过程，耗时比较长，尤其是在OLTP场景中，这个耗时往往不可忽略。
为了加速SQL请求的处理过程，SQL执行引擎会将SQL第一次生成的执行计划缓存在内存中，后续对该SQL的重复执行可以复用这个计划，避免了重复查询优化的过程。
SQL 性能问题来源
用户SQL写法 - 遵循开发规约
代价模型缺陷 - 绑定执行计划
统计信息不准确 - 仅支持本地存储，合并时更新
数据库物理设计 - 决定查询性能
系统负载 - 影响整体吞吐率，影响单sql rt
客户端路由 - 远程执行
SQL 执行计划监控
(g)v$sql_audit 是全局 SQL 审计表，可以用来查看当前server每一次SQL请求客户端来源、执行 server 信息、执行状态信息、等待事件及执行各阶段耗时等。该视图是按照租户拆分的，除了系统租户，其他租户不能跨租户查询
sql_audit 相关设置。
(g)v$sql_audit看什么
retry 次数是否很多(RETRY_CNT字段）, 如果次数很多，则可能有锁冲突或切主等情况
queue time 的值是否过大(QUEUE_TIME 字段) 很高，表明CPU资源不够用
获取执行计划时间(GET_PLAN_TIME), 如果时间很长，一般会伴随 IS_HIT_PLAN ＝ 0, 表示没有命中 plan cach
查看 EXECUTE_TIME 值，如果值过大，则：查看是否有很长等待事件耗时
分析逻辑读次数是否异常多(突然有大账户时可能会出现）
SQL audit 记录的等待事件如下相关信息：
记录了 4 大类等待事件分别的耗时（APPLICATION_WAIT_TIME, CONCURRENCY_WAIT_TIME, USER_IO_WAIT_TIME, SCHEDULE_TIME）, 每类等待事件都涉及很多具体的等待事件
记录了耗时最多的等待事件名称（EVENT）及该等待事件耗时（WAIT_TIME_MICRO）
记录了所有等待事件发生的次数（TOTAL_WAITS）及所有等待事件总耗时（TOTAL_WAIT_TIME_MICRO）
(g)v$sql_audit淘汰机制
触发淘汰的标准：当内存或记录数达到淘汰上限时触发淘汰
sql_audit 内存最大可使用上限：avail_mem_limit = min(OBServer可使用内存*10%,sql_audit_memory_limit)
淘汰记录数上限：当sql_audidt记录数超过 900w 条记录时，触发淘汰。
停止淘汰的标准：当内存或记录数达到停止下限时停止淘汰
如果是达到内存上限触发淘汰则
如果是达到记录数上限触发的淘汰则淘汰到 800w 行记录时停止淘汰。
SQL Trace
SQL Trace 能够交互式的提供上一次执行的 SQL 请求执行过程信息及各阶段的耗时。
SQL Trace 开关
SQL Trace 功能默认时关闭的，可通过 session 变量来控制其关闭和打开。
Show Trace
当 SQL Trace 功能打开后，执行需要诊断的 SQL， 然后通过 show trace 能够查看该 SQL 执行的信息。这些执行信息以表格方式输出，每列说明如下图所示：
SQL Trace-示例，查看各阶段耗时
Plan Cache 视图
SQL 调优方法
SQL 调优是指通过综合分析 SQL 的执行计划、执行监控信息、系统配置、系统负载等多方面因素，调整 SQL 的执行策略，以实现资源利用最大化。
SQL 调优方式一般可分为单条 SQL 调优和系统 SQL 调优。
针对单条 SQL 执行的性能调优
单表访问场景：索引、排序或聚合、分区、分布式并行
多表访问场景：连接顺序、连接算法、分布式并行、查询改写
针对吞吐量的性能优化：优化慢 SQL、均衡 SQL 的流量资源
