作者：越寒

介绍

如标题所示，这是一篇介绍in常量查询的源码解读文章，但又不限于in常量查询，因为其中涉及的很多设计与优化对于大多数查询都是普适的。 一如往常一样，我们首先会过一遍整体的执行流程，梳理一个大致的框架。紧接着，同时也是更重要的，我们会通过一系列在真实场景中遇到的问题（说白了就是性能优化），来对各种细节处理进行增强。

温馨提醒：建议有条件有兴趣的同学可以对照着本篇文章边调试（我基本上把重要的断点位置都截了图）边学习边思考，这样印象和理解应该会更加深刻。

希望大家在读完之后，可以尝试着回答以下一些问题来进行某种测验：

• 什么是分片裁剪？为什么要进行分片裁剪？
• 为什么要对物理SQL中值进行裁剪？
• 什么是plan cache？为什么需要？
• 为什么需要post planner ?
• XPlan是什么？为什么Xplan比物理SQL更优？
• 为什么要有一个ToDrdsRelVisitor？
• 什么是全局二级索引？如何利用？
• 以及其他散落于文章中或者阅读时的问题

从大致的流程说起

注：详细的执行流程请参考文章，https://zhuanlan.zhihu.com/p/457450880，我们这里只介绍其中几个比较重要的环节。 我们拿一个非常简单的场景来看一下吧，一个简单的表如下，create table t(c1 int, c2 int, c3 int) dbpartition by hash(c1) tbpartition by hash(c1) tbpartitions 2，一条最简单的SQL如下：select c3 from t where c1 in (1,2)。挑了五个阶段进行了并不太详尽的说明，如果你感觉比较抽象时，也可以动手调试一下，一些概念应该就会更加清晰了。

阶段一

我们需要将SQL文本解析为语法树，如果不合法，则报错，关键断点如下图，其中sql为输入的查询语句，statement为经过解析后的语法树。

需要注意的是，在这个地方，我们是只进行语法解析，而不进行语义解析。什么意思呢，比如你现在输入的SQL为select c1 from tt，此时虽然我们没有tt这张表，但是断点处还是会正常解析出一个SQLSelectStatement，有兴趣的同学可以打个断点试一下。

阶段二

如上分析，我们现在要进行语义的校验了，比如我怎么知道这张表存不存在，以及是否含有这个列呢？

阶段三

构建执行计划，在toRel时将由 SqlNode 构成的 AST 转换为由 RelNode 组成的逻辑计划。

埋一个坑把，有兴趣的同学可以结合代码思考一下，既然我们已经拿到了逻辑执行计划，那么ToDrdsRelVisitor的作用是什么呢？

阶段四
对执行计划进行优化，以期获得较为优异的执行效果。

阶段五
拿到执行计划之后，紧接着我们来看一下是在哪里执行的，以及是如何执行的。

我们可以简单看一下这个plan，这是一个非常简单的plan，最上层是一个Gather用来聚合下层多个logicalView的结果，而logicalView中包含了如何与存储节点进行交互的信息。 根据plan拿到相应的handler，然后进行调用就可以了。

在这个场景中，我们会递归调用logicalView的handler。

OK，以上就是一个大概的执行流程，接下来我们来真正深入到一些细节看一下，我们如何将这个大致的流程进行丰富以使其能够满足工业生产的需求。

现实中的使用场景

In查询列表中的值不固定，个数亦不固定。

优化思路

单条SQL的优化，比如分片裁剪，物理SQL中in值的裁剪，使用XPlan代替物理SQL。
大量执行相似的SQL时，避免重复性且不必要的工作，如避免每次重新生成plan。
对其中一些特殊场景进行更加极致的优化，比如单分片直接下推。
通过添加索引进行优化，在这里我们主要讨论全局二级索引。

具体的优化

单条SQL的优化
分片裁剪：只访问必须访问的分片
Q：select from t where c1 in (1,2) 会向所有分片下发物理SQL么？ A：不会的。通过上面的分析，我们下发的物理SQL为select from t_physical_table where c1 in (1,2)，t_physical_table为逻辑表t所对应的物理表。而由于表t的分库键和分表键均为c1，因此显然我们只需要向两张可能存在匹配记录的物理表下发物理SQL即可，获取裁剪后的分表信息如下图。

分片裁剪是一定需要调用分片计算，分片计算的逻辑在这里。

物理SQL中in值的裁剪：只留下有用的in值
Q：下发的物理SQL中，是否会对in的列表进行裁剪呢？ A：会的，而且对下发的物理SQL中的in列表中的值进行裁剪，主要有两个好处，一是尽可能避免下发的物理SQL导致不必要的全表扫描，二是减少下发物理SQL的长度。

上图中PruneRaw即代表裁剪后的in查询列表。

使用XPlan代替物理SQL：避免DN节点进行物理SQL的解析优化

注：详情可参考链接文章中的执行计划传输部分，https://zhuanlan.zhihu.com/p/308173106#:~:text=PolarDB-,%E8%BF%9B%E8%A1%8C%E4%BA%86%E7%89%B9%E6%AE%8A%E4%BC%98%E5%8C%96%E3%80%82 Notice：in查询其实暂时是不支持传输执行计划的。 但我觉得可能没什么特别特殊的地方，像传输其他的plan一样，我们需要在计算层指定数据的访问方式（即指定索引），然后进行适配和对接。

避免每次重新构建plan
避免参数值不同而反复构建plan
Q：每次都进行plan的构建，看起来并不是非常有必要，比如select from t where id in (1,2) 和select from t where id in (2,3)。
A: 是的，所以我们对plan进行了缓存，这就是PlanCache组件，可以理解为Map。很自然的，我们需要对上述两条SQL进行参数化以便从map中进行查找，即参数化为select * from t where id in (?,?)的形式，代码在

避免参数个数不同而反复构建plan
Q：细心的同学可能感觉有点奇怪，上面的select c1,c3 from t where c1 in (1,2) 参数化后为 select c1,c3 from t where c1 in (?)，而非select c1,c3 from t where c1 in (?,?)，这是为什么？
A：这样做是为了避免plan cache的膨胀，因为这样参数化之后，select c1,c3 from t where c1 in (1,2) 和select c1,c3 from t where c1 in (1,2,3,4)就是共用一个plan cache了；此外，这样还可以减少参数化SQL占用的内存，想象一下，有些SQL中in列表中的值多达几十万个呢。

单分片场景优化
Q：对于某些场景，是否有更近一步的优化，毕竟TP是需要尽可能的高性能的。
A：有的，比如单分片的场景，in列表中的值会落在同一个物理分表上。 我们可以思考下此时下面的执行计划是否可以简化？

答案是显然的，在单分片场景下，上层的Gather是完全不需要的，否则我们在执行时会有额外的执行开销。 引申：我们可以再结合前面的参数化与plan cache来理解这个问题，即参数不同的SQL的最优执行计划其实并非总是相同的，但我们为了避免每次重复生成plan，又会缓存一个plan，于是我们需要一个能够对plan进行优化的能力。 我们大概可以把这种情况分成两种，一种是参数不同导致选择的join算法不同，比如是选择bka join还是hash join，为了解决这个问题，我们引入了执行计划管理模块（SPM）；另一种则跟我们的架构有非常大的关系，因为我们下层的DN（可以简单理解为mysql）显然是具备执行各种SQL的能力的，而如果在某些参数下，经过裁剪后只剩下一个分片了，则该SQL经过物理表名的替换后可直接下发到DN执行，计算层只需要等待结果返回即可，无需做任何其他的操作。为了实现第二种效果，我们在planner阶段增加了一个阶段，叫做post planner，在post planner中会判断是否能够下推到某个分片，默认为打开，上图中为了演示需要，特意使用hint进行了关闭。

添加全局二级索引

注：索引，本质是一种修改与查询的权衡，需要用户谨慎考虑，尤其写入全局索引会带来较大的分布式事务开销。 Q：分片建已经确定了，in查询的字段没有跟分片对齐，是不是无法做分片裁剪了，还能优化么？
A：可以考虑增加全局二级索引。 我们来举个例子吧，比如table: t3(c1 int, c2 int, c3 int) dbpartition by hash(c1); SQL为select c3 from t3 where c2 in (1,2)，由执行计划可知我们无法进行分片裁剪，因此需要访问所有8个分片，如下：

现在让我们来考虑一下如何优化？ 我们的目的是希望减少访问的分片数，而之所以无法进行分片的裁剪，是因为in查询的字段和分片键没有对齐。于是解决方案也很简单，我们增加一个拆分键与in查询字段对齐的全局的二级索引即可，有关全局二级索引的介绍，可参考链接，https://help.aliyun.com/document_detail/182179.html。 比如，我们执行如下添加全局二级索引的SQL，alter table t3 add global index g_c2(c2) covering(c1, c3) dbpartition by hash(c2)，然后我们再来看下此时的执行计划，发现此时已经如我们所料进行了基于全局二级索引的分片裁剪，现在只需要扫描两个分片即可。

一个小练习
In列表中包含大量重复值时，可以如何优化？（我们现在的版本没有考虑这种情况） 比如，有一个很简单的做法，在参数化时加一个去重，如下图。

然后大家可以思考一下，需要注意什么，以及有什么问题么？

One More：横向对比与思考
大家有兴趣，有时间的，可以对比其他友商数据库进行比较与分析。

总结

其实我在这篇文章里面，抛了挺多问题，有些给了一种便于叙述却未必全面的答案，有些则完全没有回答。最后的这个总结我觉得也留给大家来写了。

更多技术好文，请关注PolarDB-X知乎号