Skip to content
Open
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
6 changes: 3 additions & 3 deletions zh-CN/4.sql-engine/6.fast-parser-plan-cache.md
Original file line number Diff line number Diff line change
@@ -1,15 +1,15 @@
# 4.5 Fast-parser 和 Plan cache 模块

这部分的主要作用是当接收到 SQL 请求时,如果能够直接查询到其对应的 Plan cash,那么就将这个查询计划返回给 Executor,避免经过长时间的 SQL 硬解析。
这部分的主要作用是当接收到 SQL 请求时,如果能够直接查询到其对应的 Plan cache,那么就将这个查询计划返回给 Executor,避免经过长时间的 SQL 硬解析。

如果对一个 SQL 而言,执行时间远大于解析时间,那么做 Plan cash 模块的作用并不大。在 OceanBase 数据库面对的高并发场景里面,比如双十一期间,下单的流量非常的大,而操作时间很短,此时解析时间过长会造成很大的影响,因此需要避免 SQL 的硬解析。

OceanBase 提出了一种叫 Fast-parser 的方式,跟原来的 Parser 没有太大区别,主要是会对一个 SQL 语句进行常量的替换,方便去做一些 match。这里通过一个例子来帮助理解 Fast-parser 和 Plan cache 的作用。

首先来看什么是 Plan cash,如下图所示,当执行了两条 SQL 之后,查询 OceanBase 中的缓存视图,发现其中没有出现第二次执行的 SQL,只出现了第一次执行的 SQL,并且缓存命中数(hit_count)增加了 1 次。
首先来看什么是 Plan cache,如下图所示,当执行了两条 SQL 之后,查询 OceanBase 中的缓存视图,发现其中没有出现第二次执行的 SQL,只出现了第一次执行的 SQL,并且缓存命中数(hit_count)增加了 1 次。

出现上述情况是因为在进行第二条 SQL 查询的时候,进行了文本替换,将第二条 SQL 替换成了`select * from t where c1=?` 这样的一条 Statement,而条 Statement 的查询计划已经缓存在数据库中了,所以会直接将查询计划交给 Executor 进行执行,记录中就不会生成第二条 SQL 对应的查询计划。

![img](https://obbusiness-private.oss-cn-shanghai.aliyuncs.com/doc/img/kernel-quickstart/V1.0.0/zh-CN/4.sql-engine/6.fast-parser-plan-cache-01.png)

为了避免使用原来的 Yacc/Bison 实际上是一个状态机的实现,OceanBase Plan 使用了 Fase-parser, 即匹配 Plan cache 时不需要将整个 SQL 去转化成一个语法树,再进行一系列复杂的状态机转换解析,而是只需要识别转换这个 SQL 语句中需要替换的部分,这也是 OceanBase 的一个优化。
为了避免使用原来的 Yacc/Bison 实际上是一个状态机的实现,OceanBase Plan 使用了 Fast-parser, 即匹配 Plan cache 时不需要将整个 SQL 去转化成一个语法树,再进行一系列复杂的状态机转换解析,而是只需要识别转换这个 SQL 语句中需要替换的部分,这也是 OceanBase 的一个优化。