AST与Postfix算法

Question

我正在创建一个能够执行SQL查询的数据库。我正在使用Flex / Bison来创建我的AST（抽象语法树）。 例如：select * from table where score＆gt; 10 *（年龄*工资）

当我评估这个AST树时，我遍历树，从左边开始，然后是右边的子树。

与muparser（http://muparser.beltoforion.de/）相比，速度更快。有没有其他方法来执行此处理？如果我使用Postfix算法（http://en.wikipedia.org/wiki/Reverse_Polish_notation）我会有更好的表现吗？

传统数据库如何执行此任务？

Answer 1

几乎要处理SQL查询，必须解析它，处理解析结果以执行查询或将其编译成查询步骤以便以后有效执行。

对于数据库，人们在执行针对数据的查询时尤其存在性能问题，尤其是如果数据库足够大，那么它主要是磁盘驻留。解析查询很少是该过程的昂贵部分。

大多数查询可以通过多种不同的方式执行，并获得相同的结果。如果您考虑代数相同但不同的查询文本/（树），尤其如此 （例如，考虑WHERE SCORE / AGE＆gt; 10 * SALARY）。

快速执行“查询执行”通常是代码生成，枚举或以其他方式生成许多等效查询，根据索引和统计信息集估计其性能，并选择最佳一堆执行。

编译器文献中充满了以非天真的方式执行此操作的复杂方案。大多数这些方案都以AST开头，将其转换为表示程序计算的某种图形，应用选择的“优化”[在DB查询的情况下，基于估计的数据访问成本]，产生最终的高级结果然后使用原生指令编译成机器代码以进行简单的数学运算，并仔细编写用于更复杂任务的库程序（例如，“join”）。

反向抛光，虽然可爱，但通常不是用于表示解析树或分析代码生成目的的非常好的方案。 （您可能会注意到它等同于AST，但事实上它并不方便访问）。它被承认但在编译器文献中几乎被忽略了。它唯一受欢迎的地方是建造所谓的threaded interpreters。虽然它们“快速”，但它们并不像编译的优化代码那么快，只有10倍或更多。