文章出处来自：
https://cloud.tencent.com/developer/article/1801026
记录下，防丢失。
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阶段读取数据块示意
图二 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查询。
这里写自定义目录标题
欢迎使用Markdown编辑器
你好！ 这是你第一次使用 Markdown编辑器 所展示的欢迎页。如果你想学习如何使用Markdown编辑器, 可以仔细阅读这篇文章，了解一下Markdown的基本语法知识。
新的改变
我们对Markdown编辑器进行了一些功能拓展与语法支持，除了标准的Markdown编辑器功能，我们增加了如下几点新功能，帮助你用它写博客：
- 全新的界面设计 ，将会带来全新的写作体验；
- 在创作中心设置你喜爱的代码高亮样式，Markdown 将代码片显示选择的高亮样式 进行展示；
- 增加了 图片拖拽 功能，你可以将本地的图片直接拖拽到编辑区域直接展示；
- 全新的 KaTeX数学公式 语法；
- 增加了支持甘特图的mermaid语法1 功能；
- 增加了 多屏幕编辑 Markdown文章功能；
- 增加了 焦点写作模式、预览模式、简洁写作模式、左右区域同步滚轮设置 等功能，功能按钮位于编辑区域与预览区域中间；
- 增加了 检查列表 功能。
功能快捷键
撤销：Ctrl/Command + Z
重做：Ctrl/Command + Y
加粗：Ctrl/Command + B
斜体：Ctrl/Command + I
标题：Ctrl/Command + Shift + H
无序列表：Ctrl/Command + Shift + U
有序列表：Ctrl/Command + Shift + O
检查列表：Ctrl/Command + Shift + C
插入代码：Ctrl/Command + Shift + K
插入链接：Ctrl/Command + Shift + L
插入图片：Ctrl/Command + Shift + G
查找：Ctrl/Command + F
替换：Ctrl/Command + G
合理的创建标题，有助于目录的生成
直接输入1次#，并按下space后，将生成1级标题。
输入2次#，并按下space后，将生成2级标题。
以此类推，我们支持6级标题。有助于使用TOC语法后生成一个完美的目录。
如何改变文本的样式
强调文本 强调文本
加粗文本 加粗文本
标记文本
删除文本
引用文本
H2O is是液体。
210 运算结果是 1024.
插入链接与图片
链接: link.
图片:
带尺寸的图片:
居中的图片:
居中并且带尺寸的图片:
当然，我们为了让用户更加便捷，我们增加了图片拖拽功能。
如何插入一段漂亮的代码片
去博客设置页面，选择一款你喜欢的代码片高亮样式，下面展示同样高亮的 代码片.
// An highlighted block
var foo = 'bar';
生成一个适合你的列表
- 项目
- 项目
- 项目
- 项目
- 项目1
- 项目2
- 项目3
- 计划任务
- 完成任务
创建一个表格
一个简单的表格是这么创建的：
| 项目 | Value |
|---|---|
| 电脑 | $1600 |
| 手机 | $12 |
| 导管 | $1 |
设定内容居中、居左、居右
使用:---------:居中
使用:----------居左
使用----------:居右
| 第一列 | 第二列 | 第三列 |
|---|---|---|
| 第一列文本居中 | 第二列文本居右 | 第三列文本居左 |
SmartyPants
SmartyPants将ASCII标点字符转换为“智能”印刷标点HTML实体。例如：
| TYPE | ASCII | HTML |
|---|---|---|
| Single backticks | 'Isn't this fun?' | ‘Isn’t this fun?’ |
| Quotes | "Isn't this fun?" | “Isn’t this fun?” |
| Dashes | -- is en-dash, --- is em-dash | – is en-dash, — is em-dash |
创建一个自定义列表
-
Markdown
- Text-to- HTML conversion tool Authors
- John
- Luke
如何创建一个注脚
一个具有注脚的文本。2
注释也是必不可少的
Markdown将文本转换为 HTML。
KaTeX数学公式
您可以使用渲染LaTeX数学表达式 KaTeX:
Gamma公式展示 Γ ( n ) = ( n − 1 ) ! ∀ n ∈ N \Gamma(n) = (n-1)!\quad\forall n\in\mathbb N Γ(n)=(n−1)!∀n∈N 是通过欧拉积分
Γ ( z ) = ∫ 0 ∞ t z − 1 e − t d t . \Gamma(z) = \int_0^\infty t^{z-1}e^{-t}dt\,. Γ(z)=∫0∞tz−1e−tdt.
你可以找到更多关于的信息 LaTeX 数学表达式here.
新的甘特图功能，丰富你的文章
- 关于 甘特图 语法，参考 这儿,
UML 图表
可以使用UML图表进行渲染。 Mermaid. 例如下面产生的一个序列图：
这将产生一个流程图。:
- 关于 Mermaid 语法，参考 这儿,
FLowchart流程图
我们依旧会支持flowchart的流程图：
- 关于 Flowchart流程图 语法，参考 这儿.
导出与导入
导出
如果你想尝试使用此编辑器, 你可以在此篇文章任意编辑。当你完成了一篇文章的写作, 在上方工具栏找到 文章导出 ，生成一个.md文件或者.html文件进行本地保存。
导入
如果你想加载一篇你写过的.md文件，在上方工具栏可以选择导入功能进行对应扩展名的文件导入，
继续你的创作。
注脚的解释 ↩︎
扫一扫
9987
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
