关于数据库:KunlunDB查询优化三排序下推

前言

后面2篇文章咱们介绍KunlunDB的查问优化原理和Project和Filter下推演示（KunlunDB 查问优化（一），KunlunDB查问优化（二）Project和Filter下推），本节讲述排序查问优化之排序下推。

一、order by下推

一条含有order的SQL的执行打算在如下生成过程中，Sort被下推到RemoteScan算子外面。

Sort下推的操作是异步形式，指令在各个数据节点并行执行，过滤数据后，将排序后的后果反馈给计算节点，升高了计算节点的负载。

上面咱们来测试查看查问下推的执行打算

为反对排序下推，须要在kunlunDB设置如下如下参数为true：

set enable_remote_orderby_pushdown=true;

测试语句：

select c_zip from customer1 order byc_zip;

查看执行打算：

explain select c_zip fromcustomer1 order by c_zip;

依据下面的执行打算，RemoteScan在传播了近程排序操作到每一个相干的存储节点，存储节点将后果反馈给计算节点再做Merge Append。

如果敞开排序下推的个性，执行打算会发生变化，排序操作将在计算节点执行。

演示如下：

set enable_remote_orderby_pushdown=false;

排序操作将在计算节点执行：

语句的执行过程：语句在计算节点改写后，下发到2个数据节点执行，从计算节点拉取符合条件的值到计算节点排序，排序后反馈给客户端。

二、性能比对

性能比对环境：

复制下方链接登录kunlunDB在线体验零碎：

zettatech.tpddns.cn:8000/ci/index.php/Main/PGList

在SQL框中输出排序操作的语句，按执行键执行。

右边窗口是KunlunDB社区版本的执行信息（社区版不反对排序下推操作），左边窗口是KunlunDB企业版有下推操作的执行信息。

比照能够发现，order by下推后，执行效率进步了（执行工夫由4毫秒降落到3毫秒）

*KunlunDB我的项目已开源

【GitHub：】
https://github.com/zettadb

【Gitee：】
https://gitee.com/zettadb

END