共计 942 个字符，预计需要花费 3 分钟才能阅读完成。
前言
后面 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
