共计 775 个字符，预计需要花费 2 分钟才能阅读完成。
前言
有敌人之前看过 KunlunDB 的架构以及技术介绍后，比拟好奇其查问优化的过程，本篇章带来的是查问优化这一块的具体流程介绍，后续也会出一篇实例来举例演示。
当然后续也会对 KunlunDB 的其它技术方面（比方数据分片这些）做实例演示，以不便大家去理解 KunlunDB。
查问优化流程
KunlunDB 是计算和存储拆散的分布式数据库系统，当一条查问 SQL 发送到 KunlunDB 任一计算节点（CN）时，KunlunDB 语法解析器（Parser）首先会对原始查问文本做出解析以及一些简略的合法性验证，之后会对查问做逻辑优化：如查问重写，分区修剪，列裁剪，谓词下推等。
KunlunDB 在逻辑优化过程中会采取最大下推的策略。
计算下推岂但能够防止 CN 和 DN 间数据网络交互还能够充分利用多分片并发执行的能力和各个 DN 资源，减速查问。
优化后的算子分为两类：
- 能够下推的算子：RemoteScan 将该算子推送到对应的数据节点上执行，执行实现后拉取相应的数据到计算节点做后继解决。反对下推的算子包含：过滤条件，如 WHERE 或 HAVING 中的条件。聚合算子，如 COUNT，GROUP BY 等，会分成两阶段进行聚合计算。排序算子，如 ORDER BY，JOIN 和子查问。Project, 投影操作。Distinct 排重。
- 无奈下推的局部算子：如跨 shard 的 join，须要将数据从数据节点拉取到计算节点做计算，优化器会抉择最优的形式来执行，如抉择适合的并行度策略等
全局执行流程如下：
优化流程如下：
最大下推策略如下：
综述：为获取最大性能，在定义分区键时要充分考虑业务在执行 SQL 语句的场景，以最大限度防止跨节点数据操作。
*KunlunDB 我的项目已开源
【GitHub：】
https://github.com/zettadb
【Gitee：】
https://gitee.com/zettadb
END
正文完
