比开源快30倍的自研 SQL Parser 设计与实践

SQL（Structured Query Language）作为一种领域语言（编程语言），最早用于关系型数据库，方便管理结构化数据；SQL由多种不同的类型的语言组成，包括数据定义语言，数据控制语言、数据操作语言；各数据库产品都有不同的声明和实现；用户可以很方便的使用SQL操作数据，数据库系统中的词法语法分析器负责分析和理解SQL文本的含义，包括词法分析、语法分析、语义分析3部分。经过词法语法分析器生成AST（Abstract Syntax Tree），会被优化器处理生成生成执行计划，再由执行引擎执行，下图以MySQL架构为例展示词法语法分析器所处的位置。

本文通过介绍词法语法分析器技术和业界的做法，以及过去使用自动生成的词法语法分析器遇到的问题，分享自研SQL Parser的设计与实践，以及其带来的性能和功能的提升。

一 业界产品如何开发SQL Parser？

按照解析器代码开发方式，可分为以下两种：

1 自动生成

为方便开发词法、语法分析的过程，业界有许多词法、语法分析工具，例如：Flex、Lex、Bison工具常用于生成以C、C++作为目标语言的词法、语法代码；如果以Java作为目标语言，可以使用比较流行的ANTLR和JavaCC等工具，ANTLR、JavaCC工具都以用户编写的词法语法规则文件作为输入，其中语法文件需要满足EBNF（extended Backus–Naur form）[1]语法规则， 这2个工具使用LL(k) (Left-to-right, Leftmost derivation)[2] 算法“自顶向下[3]”解析SQL文本并构建SQL AST， Presto，Spark、Hive等数据库和大数据系统多采用该方式生成。生成的代码包含词法和语法解析部分，语义分析还需要结合Meta数据，各数据库内核自己处理；更多自动生成工具的功能和算法对比[4]在参考文献中。

2 手工编写

与自动生成工具不同，InfluxDB、H2、Clickhouse等流行的数据库的SQL Parser组件均是手工编写而成。

优点：

• 代码逻辑清晰，方便开发人员调试和排错；
• 性能更好：有更多代码优化的空间交给开发人员，可以使用更优秀的算法和数据结构提升性能；
• 自主可控：无licence约束，可读性和可维护性更高；
• 不需要额外依赖第三方词法语法代码生成工具。

不足：

• 对开发人员的技术要求较高，需了解编译原理技术；
• 开发工作量较大，实现MySQL常用语法的各类分支，需要投入很多时间和精力；
• 需要长时间、大规模测试才会趋于稳定。

二 问题与挑战

1 复杂查询的性能问题

在实时分析型数据库的实际生产环境中，经常需要处理数以千行的复杂查询请求或者深层嵌套的查询请求，自动生成的解析器，由于状态机管理复杂，线程堆栈太深，导致个别查询请求在词法语法解析阶段性能下降严重。

2 大批量写入吞吐问题

分析型数据库要稳定处理大批量、高并发写入的场景，要求SQL Parser组件有很好的性能和稳定性，我们尝试使用过ANTLR，JavaCC等工具生成SQL