Clickhouse在OLAP查询场景下有显著的性能优势，但Clickhouse在大表join查询的场景下，性能表现并不是很好，因此在实际业务场景需要多表计算时，往往是通过in 子查询的方式代替join查询，以提升查询性能。
笔者在最近的业务开发中，尝试用这种方式，性能却没有想象中那么好。分析Clickhouse的查询计划，发现子查询中的语句会多次执行，且性能开销主要来自于子查询的执行，因此总体上查询耗时很长。通过网上资料查询以及本地实验，最终在查询语句中用Global in代替in解决了子查询执行多次的问题。但在这个过程中，笔者发现网上几乎没有对该问题的解释，因此在这里记录一下，希望能对他人有所帮助。
一、发现问题
笔者最近的业务场景是人群包筛选，即根据用户的属性和行为筛选出满足特定人群画像的人。简单起见，可以把业务数据抽象成3张表（都是非分布式表），用户表user（用户及其社交账号表，社交账号指手机、微信账号等）、属性表user_attr（用户的属性，如性别、年龄等）、行为表user_action（用户参加过哪些活动）。
典型业务查询就可以用如下的SQL表示：
代码语言：txt复制select distinct(sa_value) from user
where user_id in
(
select user_id from user_attr where age > 10
)
and user_id in
(
select user_id from user_action where action_name = '世界杯'
);其中年龄大于10岁且参加过“世界杯”就是目标人群画像。实际业务场景会比这个查询复杂一些，可能会有更多的“user_id in xxx”条件（因为实际业务中属性和行为都可能分布在多个表中），但查询语句的模式不会变。
笔者信心满满的把这个查询语句丢到Clickhouse中，却发现，上述简单的查询却要执行2-3s，而单独执行内层的子查询只需要0.3-0.4s；多个条件的平铺倒是还好，只会增加一点点查询耗时，但业务场景复杂一点，用到多层嵌套的in 子查询时，查询耗时是随嵌套层数指数增加的。
下表是笔者使用测试数据，对同一张表写多层嵌套查询语句（每层的查询语句都是相同的）的测试结果，测试数据及查询结果都相同，可以看到每增加一层嵌套子查询，查询耗时基本要增加一倍。
子查询嵌套层数 | 查询耗时 |
|---|---|
1 | 26ms |
2 | 35ms |
3 | 63ms |
4 | 104ms |
5 | 191ms |
6 | 369ms |
7 | 742ms |
8 | 1503ms |
9 | 3214ms |
二、问题分析及解决
Clickhouse是利用多核并行计算提升查询性能的，因此理论上在机器核心数足够的情况下，对于如下查询语句（A、B均表示某个子查询语句），A、B子查询是可以并行计算的，更多的子查询条件不会明显改变查询耗时。执行计划应该是子查询A和B都应分别计算一次，最后计算一次外层查询。但图一中该查询的查询日志显示，A、B子查询都被执行了2次。
代码语言：txt复制select distinct(sa_value) from user
where user_id in A and user id in B ......
图一 查询计划示意图对于如下所示多层嵌套查询来说，理论上查询耗时应该是A、B、C单独执行耗时之和再加上最外层查询的耗时（因为需要先计算出子查询C的结果，将“user_id in C”当做一部分条件带入子查询B，然后计算出子查询B的结果，将“user_id in B”当做一部分条件带入子查询A，最后计算出子查询A，这3步是不能并行的）。执行计划应该是C、B、A依次执行一次，最后计算一次外层查询。但查看查询日志发现A被执行了2次、B被执行了4次、C被执行了8次。这也就解释了为什么多层嵌套查询的耗时会随层数指数增加。
代码语言：txt复制select distinct(sa_value) from user
where user_id in
(
A and user_id in
(
B and user_id in C
)
)而笔者的业务场景中查询比较耗时的部分就是子查询部分（过滤用户的属性和行为），因此子查询多次执行直接导致了查询耗时较大。
在网上找了很多博客和文档，都没有明确提及过这个问题。搜索子查询多次执行，搜到的文章都是说Clickhouse分布式表查询中，in子查询会被执行多次，可以用Global in代替in来避免多次执行[1]。但官网文档同时又说明对于非分布式表，请用in查询而不要用Global in。带着试一试的态度，我把上面的非分布式表查询也替换为Global in试了一下，结果查询耗时大幅降低（3s->0.8s），查询计划中子查询多次执行的情况也没有了，执行计划完全符合预期。
三、原因分析
为什么Clickhouse中in子查询会被执行多次呢？为什么Global in可以解决子查询执行多次的问题呢？在网上查了很多资料，最终github上Clickhouse的一个issue给了我思路[2]。
解释这个问题，要从Clickhouse MergeTree引擎的数据存储结构说起。MergeTree表由许多Data Part组成，Data Part在后台可以合并，形成新的Data Part；每个Data Part中的数据是按照主键排序存储的，并且主键有一个类似跳表的索引，依据跳表的key，将Data Part分为多个数据块（Granule），数据块就是MergeTree表中数据读取的最小单元。
接下来就要说到Clickhouse的prewhere查询和where查询了。Clickhouse执行where查询就是对数据做全表扫描，过滤掉不满足条件的行；而prewhere查询则可以利用分区信息和主键信息进行高效的分区修剪，在读取数据之前就依据分区和主键索引过滤掉无关的数据块，减少从磁盘读取的数据量，提升查询效率。需要注意的是，prewhere过滤之后的读取的数据块中包含满足条件的行，但并不是数据块中所有的行都满足查询条件。如图二所示，当查询条件为user_id=123时，左侧两个数据块都会被读取，但其中并不是每一行都满足user_id=123。
图二 prewhere阶段读取数据块示意一般查询语句中只会写where查询，但在执行时，Clickhouse会根据条件里是否有分区键、主键等信息，将where查询优化成prewhere查询，提升整个查询的执行效率。
有了上面的知识背景，再来分析如下的查询语句：
代码语言：txt复制select distinct(sa_value) from user where user_id in A假设user_id在user表的主键中，“user_id in A”这个条件就会被默认优化成prewhere条件，即执行该查询时，第一步会用该条件过滤数据块，此时就需要子查询A的计算结果，这就是子查询A的第一次执行。在prewhere阶段之后，从磁盘中读取了所有满足条件的数据块，但并不是其中的每一行都满足“user_id in A”的条件，于是必须要执行where阶段的行扫描，精准过滤出哪些行满足“user_id in A”的条件，此时又需要子查询A的计算结果，于是子查询A被第二次执行。对于多层嵌套的in子查询也是同样的道理，如果带子查询的条件命中了外层查询表的主键，那么外层查询执行1次，子查询就要执行2次。
这并不是说Clickhouse的prewhere优化有bug，因为Clickhouse很难判断这种情况下是用prewhere执行比较好，还是直接用where执行比较好。例如，当user表很大，而A子查询执行的开销很小时，全表扫描user表中的数据开销远比多执行一次A子查询开销大，这时使用prewhere优化可以提升执行效率。而在笔者的应用场景中，是子查询A（用户属性表、行为表过滤）执行的开销较大，因此禁用掉prewhere优化可以带来性能的提升。
目前Clickhouse集群的optimize_move_to_prewhere参数可以控制是否使用prewhere优化，但它是一个全局设置，关掉该开关将使所有查询都无法使用prewhere优化。对于in子查询条件，将in替换为Global in可以使子查询先执行并将结果保存在临时表中，这种方式可以避免子查询多次执行，但同时该条件也就无法被优化为prewhere查询。
参考文献
[1] Clickhouse官方文档，https://clickhouse.tech/docs/zh/sql-reference/operators/in/
[2] https://github.com/ClickHouse/ClickHouse/issues/13961
