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毫秒）

END