GBase 8a MPP Cluster數據庫采用分布式大規模并行處理架構，常用于OLAP分析型場景。此類場景中通常基礎數據量比較大，不同SQL運行時長差異較大。不同于MYSQL等交易型數據庫，其負載多為高并發的短事務類型，慢查詢SQL任務可通過設置固定閾值來統一對執行時間過長的SQL進行記錄，分析型場景由于業務特點存在SQL正常執行時間從幾秒鐘到幾小時都有可能，因此無法通過簡單方式來判斷SQL任務是否異常。本文總結了GBase 8a MPP Cluster數據庫中SQL運行緩慢的分析排查和優化方法，供其他用戶參考。

排查和優化方法

SQL任務歷史性能對比分析：

通過開啟GBase 8a的audit_log審計日志，可以連續收集周期性任務的執行時間，通過對比相同SQL任務歷史執行時長可以判定相同任務SQL長周期內的執行耗時趨勢，通過對比發現執行性能異常情況，并進行針對性的分析。如，相同SQL任務在一定周期內執行時間逐漸變長，則需要結合表內數據量變化趨勢、SQL任務類型需要訪問全量數據還是只訪問增量數據等進行分析。

執行計劃分析：

對于性能異常的SQL，通常先通過執行計劃分析執行步驟是否存在可優化的空間。GBase 8a提供的explain分布式執行計劃，可以提供SQL任務的執行順序和步驟，常見的執行計劃中的問題和優化方法包括：

• 避免不合理的動態重分布或者拉復制表降低數據在節點間重分布的代價；

• 檢查join列的字段類型，避免因字段類型不一致導致的數據動態重分布；

• 調整不合理的join順序，避免出現笛卡爾積導致中間結果集過大；

• 評估哈希索引的必要性，去除不必要的哈希索引；

表數據分布分析：

通常表在各節點間的數據分布會影響查詢性能，當表數據分布在節點間出現嚴重的傾斜分布時，不同的節點會因處理的數據量差異較大出現木桶效應。對于數據分布存在嚴重傾斜的表，可以通過調整表的分布鍵方式將數據均勻打散，常見的分布鍵選擇策略包括：

• 優先考慮大表間的JOIN，盡量讓大表JOIN條件的列為Hash分布列（相關子查詢的相關JOIN也可以參考此原則），以使得大表間的JOIN可以直接下發到各節點分布式執行；

• 其次考慮GROUP BY，盡量讓GROUP BY帶有Hash分布列，讓分組聚合一步完成；

• 當有多個join或group列可選擇時，優先選擇唯一值多（count(distinct)值大）的列做Hash分布列，讓數據均勻分布；

• 通常是等值查詢的列，并且使用的頻率很高的應考慮建立為hash分布列；

通過詳細trace日志分析SQL任務瓶頸：

對于一些慢SQL需要詳細分析各節點的執行日志，通過日志發現某個節點是否相較其他節點明顯執行緩慢，如果存在較慢的節點則進一步排查是什么原因導致的。常見的情況有數據傾斜、并發過高、參數設置不合理、數據分布特征等原因造成。需要根據不同的情況，通過調整表數據分布、設置合理的線程池和并行度（主要排查gbase_parallel_execution、gbase_parallel_degree以及gbase_parallel_max_thread_in_pool等參數）、調整操作系統參數、使用hint影響具體執行計劃等方式進行調優。

各節點軟硬件參數配置檢查：

排查CPU超線程、虛擬內存、透明頁和IO調度參數等配置項，查看是否按照廠商建議進行配置。

總結

分布式分析型數據庫由于其多節點并行的部署環境及OLAP負載類型復雜的特點，其SQL任務調優相比傳統單機交易型數據庫更加復雜，需要更加系統的方法論指導，本文的目的在于對日常運維工作中針對GBase 8a數據庫的SQL性能分析和優化思路進行總結，期望對從事數據庫運維工作的讀者提供一些可以借鑒的思路和方法，達到交流思路互相學習的目的。