sql改写优化：简单规则重组实现

　　我们知道sql执行是一个复杂的过程，从sql到逻辑计划，到物理计划，规则重组，优化，执行引擎，都是很复杂的。尤其是优化一节，更是内容繁多。那么，是否我们本篇要来讨论这个问题呢？答案是否定的，我们只特定场景的特定优化问题。

1. 应用场景描述

　　应用场景是：我们提供一个功能，允许用户从提供的字段列表中，选择任意字段，然后配置好规则，后端根据这些规则，查询出相应的主键数据出来。可以理解为简单的可视化查询组件。

2. 整体思路解析

　　一般地，为了让前端规则支持任意配置，我们基本很难做到一种特定的数据结构，将每个查询条件拆分到一个个的rdb表字段中。所以，简单地，就是让前端直接提交一个用户的整个查询规则上来就好了，这和数据库中的sql其实是一个道理，只是这里只有where条件。所以，我们要做的就是，如何根据where条件，构建出相应的sql问题了。

　　只有where条件规则的模式，既有好处也有不好的。首先说不好处，就是只有where条件，如何构建其他部分相对麻烦点，但因为我们只考虑主键查询，所以相对简单。其次好处是，我们可以在这个where条件的后面，任意转换成各种数据库查询，即我们存储层是可替换的，这就给了我们很多想像的空间。比如，最开始业务量小，我们用简单rdb，后来可以换成es，再可以换成其他数据库。这就很方便了。

　　那么，如何从一串where条件中，提取出关键信息，然后反解出整体概念呢？很简单，只需要将条件分词，分析一下就知道了。更直接的，我们从条件中提取出相应的元数据信息，再根据这些元数据就可以推导出上下文了。然后，再连接上where条件，自然就构建出完整的查询语句了。

　　但是有个问题，如果我们的整体where结构是不变的，那么好办，直接拼接或者简单的改写局部即可。但，如果我们想拆解成尽可能小的执行步骤呢？也就是本文标题指向，想尽可能把符合一个表的条件放在一块，甚至分解一个大的where条件为多个子查询，那又该如何呢？

解题思路：
　　1. 分解出所有的元数据信息；
　　2. 构建出所有查询的抽象语法树，树尽可能简单；
　　3. 根据元数据信息，将同表的查询条件聚合在一起；
　　4. 根据条件运算优先级，将相同优化级的条件聚合在一起；
　　5. 重新构建整体sql；

　　说得有点抽象，来个图表示一下。

规则定义为：a1.f1 > 1 and a2.f2 < 0 and a1.f3 <> 'x' or a2.f4 > 'q'

原始规则树如下：

改写后的规则如下：

3. 实现步骤细节

　　大体上就是干这么一件事，以及如何干成。看起来好像蛮简单的，相信聪明如你也许早就做出来了。但是我还是要提醒大家，需要注意的事情其实也有那么几件。

1. 分词倒是简单，但也得做；
2. 如何构建原始二叉树？注意需要保持各优先级问题；
3. 改写的前提是什么？不是所有改写都能成立；

　　也许，我们应该用到一些开源的框架，以便让我们事半功倍。比如，我使用calcite框架的实现思路，将各单词构建出二叉树，因为calcite中有各种测试好的优先级定义，我只拿过来就即可。比如我暂且定义优先级如下：

    /**
     * 获取各操作符的优先级定义
     *      and              ->  24
     *      or                 ->  22
     *      <,<=,=,>,>=      ->  30
     *      NOT              ->  26
     *      IN               ->  32
     *      IS_NULL          ->  58
     *      IS_NOT_NULL      ->  -
     *      LIKE             ->  32
     *      BETWEEN          ->  32
     *      +,-              ->  40
     *      /,*              ->  60
     *      between..and     ->  90
     *
     * @see PrecedenceClimbingParser #highest() calcite 优先级定义
     *      org.apache.calcite.sql.fun.SqlStdOperatorTable
     */
         private static int getTokenPrecedence(SyntaxToken token) {
        if(token.getTokenType() == SyntaxTokenTypeEnum.COMPARE_OPERATOR) {
            return 30;
        }
        String keyword = token.getRawWord();
        if("and".equalsIgnoreCase(keyword)) {
            token.changeTokenType(SyntaxTokenTypeEnum.SQL_AND);
            return 24;
        }
        if("or".equalsIgnoreCase(keyword)) {
            token.changeTokenType(SyntaxTokenTypeEnum.SQL_OR);
            return 22;
        }
        if("in".equalsIgnoreCase(keyword) || "not in".equalsIgnoreCase(keyword)) {
            return 32;
        }
        if("is".equalsIgnoreCase(keyword)) {
            token.changeTokenType(SyntaxTokenTypeEnum.SQL_IS);
            return 58;
        }
        if("like".equalsIgnoreCase(keyword) || "not like".equalsIgnoreCase(keyword)) {
            return 32;
        }
        if("+".equalsIgnoreCase(keyword) || "-".equalsIgnoreCase(keyword)) {
            return 40;
        }
        if("*".equalsIgnoreCase(keyword) || "/".equalsIgnoreCase(keyword)) {
            return 60;
        }
        if(token.getTokenType() == SyntaxTokenTypeEnum.SQL_BETWEEN_AND) {
            return 90;
        }
        // 非操作符
        return -1;
    }

　　然后，我需要假设场景再简单些，比如所有小规则都被括号包裹（这其实就不太灵活了，不过没关系，至少我们实践初期是可行的）。这样的话，构建原始规则树就容易了。

    /**
     * 按照括号进行语法分隔构建语法树
     *
     * @param rawList 原始单词列表
     * @param treeList 目标树存放处
     * @return 当次处理读取的单词数
     */
    private static int
        buildByPart(List