免費體驗彈性并行查詢ePQ
本文介紹了如何免費體驗彈性并行查詢ePQ帶來的查詢加速及性能提升。
背景
PolarDB MySQL版8.0版本重磅推出彈性并行查詢（Elastic Parallel Query，ePQ）：將一個復雜查詢任務拆分為多個子任務，子任務可以被派發到同集群內的任意節點并發完成計算，從而有效利用集群內其他節點的空閑計算資源（CPU、內存等）來加速查詢，使查詢耗時指數級下降，并有效提升集群的資源利用率。
彈性并行查詢（ePQ）的優勢如下：
實時性分析：統一的底層存儲，數據實時可見
開箱即用：零附加成本和運維成本，隨集群部署
性能優異：打通節點間的計算資源，突破單機硬件性能瓶頸，性能表現優異
提升能效：充分利用空閑計算資源，提升集群整體資源利用率
實時彈性：按需擴容，提供更靈活的彈性計算能力
阿里云提供了數據庫解決方案功能體驗館，提供真實免費的PolarDB集群環境和開箱即用的測試方法，您可以在線快捷體驗ePQ帶來的查詢效率提升。
影響
本功能體驗不涉及生產環境的部署，因此不會影響業務。
費用
本次體驗中，由于體驗涉及到的資源不歸屬于您，因此不會產生任何費用，您可以放心體驗。
體驗內容
體驗環境
在本免費體驗中，阿里云提供了預置環境供您操作體驗，預置環境的詳情如下：
集群：提供了一個PolarDB MySQL版集群。具體如下：
內核版本： 8.0.2.2.19.1
產品版本：企業版
系列：集群版通用規格
集群規格：集群包含1個主節點和1個只讀節點，規格都為8核 16GB
存儲類型： PSL5
參數設置：
parallel_degree_policy參數初始設置為TYPICAL
測試數據集：集群中預置了標準測試集TPCH 100G的數據集，其中具體查詢所用的表為part表，數據量為20,000,000條數據。
觀測指標
CPU占用率：集群中主節點和只讀節點的平均CPU使用率。單位：%。
查詢耗時：執行特定SQL所耗費的時間。單位：秒。
操作步驟
進入瑤池解決方案體驗館。
單擊核心功能體驗，然后單擊彈性并行查詢-PolarDB查詢加速的免費體驗按鈕，進入如下頁面：
單擊頁面下方創建免費體驗任務按鈕。
稍等片刻后，單擊
刷新任務列表，可以看到您創建的體驗任務已開始。
單擊查看詳情，進入實時查詢體驗頁面。
首先進行未開啟ePQ的正常查詢任務。
說明請根據頁面按鈕提示，手動點擊按鈕執行每一步操作。若在倒計時結束時沒有手動點擊執行，則會自動執行對應操作。
單擊啟動任務按鈕開始體驗。
單擊配置查詢庫按鈕，自動向PolarDB集群執行如下命令，切換至
tpch數據庫：use tpch;單擊配置并行策略為LOCAL按鈕，自動執行如下命令，將數據庫的并行策略設置為LOCAL，即
set parallel_workers_policy='LOCAL' ;單擊配置并行度為0按鈕，自動執行如下命令，將數據庫的并行度設置為0。
set max_parallel_degree=0;單擊查看執行計劃按鈕，自動執行如下命令，查看如下SQL的執行計劃。
explain format=TREE SELECT SUM(p_retailprice), AVG(p_retailprice) -> , MIN(p_retailprice), MAX(p_retailprice) -> FROM part -> GROUP BY p_type -> ORDER BY 1 -> LIMIT 1;執行計劃返回如下：
+------------------------------------------------------------------------------+ | EXPLAIN | +------------------------------------------------------------------------------+ | -> Limit: 1 row(s) -> Sort: <temporary>.sum(p_retailprice), limit input to 1 row(s) per chunk -> Table scan on <temporary> -> Aggregate using temporary table -> Table scan on part (cost=2123689.64 rows=19896680) | +------------------------------------------------------------------------------+ 1 row in set (0.00 sec)可以看到，在正常的查詢計劃中，表掃描和聚集計算都是在一個線程中串行完成。
單擊執行SQL按鈕，自動執行上一步執行計劃中的SQL：
SELECT SUM(p_retailprice), AVG(p_retailprice) -> , MIN(p_retailprice), MAX(p_retailprice) -> FROM part -> GROUP BY p_type -> ORDER BY 1 -> LIMIT 1;返回結果如下，執行時間為22.47秒。
+--------------------+--------------------+--------------------+--------------------+ | SUM(p_retailprice) | AVG(p_retailprice) | MIN(p_retailprice) | MAX(p_retailprice) | +--------------------+--------------------+--------------------+--------------------+ | 198461679.87 | 1498.366804 | 901.47 | 2098.51 | +--------------------+--------------------+--------------------+--------------------+ 1 row in set (22.47 sec)整個過程中，您可以在左側趨勢圖中觀測集群平均CPU使用率的變化情況。
在正常查詢完成后，任務將自動切至ePQ查詢任務。請根據頁面按鈕提示，手動點擊按鈕執行每一步操作。若在倒計時結束時沒有手動點擊執行，則會自動執行對應操作。
單擊配置跨機并行查詢按鈕，自動執行如下命令，開啟ePQ功能。
set parallel_workers_policy='MULTI_NODES';單擊配置并行度為4按鈕，自動執行如下命令，設置ePQ的并行度為4。
set max_parallel_degree=4;單擊查看執行計劃按鈕，自動執行如下命令，查看相同SQL的執行計劃。
explain format=TREE SELECT SUM(p_retailprice), AVG(p_retailprice) -> , MIN(p_retailprice), MAX(p_retailprice) -> FROM part -> GROUP BY p_type -> ORDER BY 1 -> LIMIT 1;執行計劃返回如下：
+-----------------------------------------------------------------------------------------------------------------------------------+ | EXPLAIN | +-----------------------------------------------------------------------------------------------------------------------------------+ | -> Limit: 1 row(s) (cost=2026377.94 rows=1) -> Gather (merge sort; slice: 1; workers: 8; nodes: 2) (cost=2026377.94 rows=8) -> Limit: 1 row(s) (cost=2026366.65 rows=1) -> Sort: <temporary>.sum(p_retailprice), limit input to 1 row(s) per chunk (cost=2026366.65 rows=248708) -> Table scan on <temporary> -> Aggregate using temporary table (cost=2026366.65 rows=248708) -> Repartition (hash keys: part.p_type; slice: 2; workers: 8; nodes: 2) (cost=1767690.54 rows=248709) -> Table scan on <temporary> -> Aggregate using temporary table (cost=1732861.35 rows=248708) -> Parallel table scan on part, with parallel partitions: 798 (cost=265461.20 rows=2487085) | +-----------------------------------------------------------------------------------------------------------------------------------+ 1 row in set (0.00 sec)可以看到，在ePQ下的查詢中，該查詢中的表掃描和聚集計算均被下推到了2個節點一共8個worker線程中并發計算。
單擊執行SQL按鈕，自動執行該SQL：
SELECT SUM(p_retailprice), AVG(p_retailprice) -> , MIN(p_retailprice), MAX(p_retailprice) -> FROM part -> GROUP BY p_type -> ORDER BY 1 -> LIMIT 1;返回結果如下，執行時間為2.82秒。
+--------------------+--------------------+--------------------+--------------------+ | SUM(p_retailprice) | AVG(p_retailprice) | MIN(p_retailprice) | MAX(p_retailprice) | +--------------------+--------------------+--------------------+--------------------+ | 198461679.87 | 1498.366804 | 901.47 | 2098.51 | +--------------------+--------------------+--------------------+--------------------+ 1 row in set (2.82 sec)整個執行SQL的過程中，您可以在左側趨勢圖中觀測集群平均CPU使用率的變化情況。
說明由于實時監控數據可能存在延遲，為了確保展示完整的CPU變化情況，趨勢圖中會在SQL執行完后，自動延長一定監控時間（2~3秒）。
（可選）對于已創建的任務，您可以在彈性并行查詢ePQ頁面，單擊體驗記錄，在彈出的面板中，單擊全部任務或我的任務，查看體驗結果詳情。
結果分析
ePQ極大地提升了查詢效率
從執行時間上看，當開啟ePQ后，復雜查詢的執行時間大幅縮短，從22.47秒縮短至2.82秒。
從執行計劃上看，執行的SQL語句是進行SUM聚集計算。
在正常查詢的執行計劃中，該查詢中表掃描和聚集計算都是在一個線程中串行完成；
在ePQ查詢的執行計劃中，該查詢中表掃描和聚集計算均被下推到了2個節點共8個worker線程中并發計算。
ePQ充分利用空閑計算資源，提升了集群整體資源利用率
從集群平均CPU占用率上看，ePQ查詢下的CPU占用率比正常查詢高。這是因為開啟ePQ后，充分利用空閑計算資源，讓空閑的計算節點也加入計算。
由于實時監控數據可能存在延遲，為了確保展示完整的CPU變化情況，趨勢圖中會在SQL執行完后，自動延長一定監控時間（2~3秒）。
在實際應用場景中，您可以自由設置并行度，從而實現對CPU占用率的調控。
相關內容
專家面對面
您可以加入官方釘釘群進行咨詢，獲取更多技術支持。釘釘群號：12810035247。