我们知道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