摘要： 性能調優是應用遷移或開發過程當中的關鍵步驟，同時也在整個項目實施過程當中佔據很大的分量，本篇主要介紹數據庫級別的性能調優思路和整體策略。
性能調優是應用遷移或開發過程當中的關鍵步驟，同時也在整個項目實施過程當中佔據很大的分量，在不少實施步驟中都須要進行考慮，從開始的數據建模，表定義的設計，到數據庫硬件、集羣部署的選擇，再到數據庫系統級調優、數據表結構設計，以及單個SQL語句的編寫及調優，都要考慮對性能的影響。數據庫
同時，性能調優一般沒有明確的衡量標準，沒有明確的對錯之分，一般須要的隱式技能比較多，使得其的技術含金量得以提高。一般來看，要作到一個性能調優的高手，除了對於應用程序的邏輯作到遊刃有餘外，還須要對應用的數據庫的基本實現原理有所瞭解，更甚者，還須要對操做系統、網絡等基礎知識有所涉獵，同時還要具有性能診斷和分析技巧。固然，性能調優是一個不斷積累的過程，你們不用考慮一步到位，惟有進行實踐的積累，才能在廣闊的調優戰場所向披靡。網絡
本篇博文做爲《GaussDB(DWS)性能調優系列》的專題文章，主要介紹數據庫級別的性能調優思路和整體策略，包括系統級和語句級調優。同時，《GaussDB(DWS)性能調優系列》文章分爲基礎篇和實戰篇，各位讀者在經過基礎篇文章瞭解數據庫的基本原理後，能夠結合調優思路，對實戰篇的各個調優技巧進行深刻的學習。有關整個調優過程當中的其它方面，後續論壇會推出其它博文進行介紹。架構
1. GaussDB DWS執行架構及說明
GaussDB DWS是典型的share-nothing架構，其計算組件的示意圖如上圖所示，主要由CN（Coordinator）和DN（DataNode）組成。CN是整個集羣的協調者，是整個集羣與應用進行鏈接處理的門戶，用於接收客戶的SQL語句並返回執行結果。DN是集羣進行數據計算的主體，各個DN擁有獨立的存儲和計算資源，使得各個DN能夠獨立地進行計算。GaussDB DWS支持多CN架構，一般應用程序會經過LVS（負載均衡設備）將語句均勻分發到各個CN上，以減小單個CN的瓶頸做用。負載均衡
GaussDB DWS的SQL處理流程如上方右圖所示，其包含如下幾個主要步驟：（1）CN經過驅動或客戶端接收到一條SQL後，會進行解析、優化，並最終返回執行結果；（2）CN進行優化後，生成相應的執行計劃；（3）CN將相同的執行計劃下發到各個DN進行執行；（4）若是DN之間須要進行數據交換，則執行計劃中包含流操做算子Stream，DN之間同步經過Stream算子進行數據交換，共同完成計劃的執行並向CN返回結果。同時，GaussDB DWS對於不須要DN間數據交換的語句，還支持語句下發到DN生成計劃；對於部分不支持分佈式查詢的語句，生成不能下推的計劃（此計劃對於大數據量性能較差）。各類計劃的對比可詳見博文《GaussDB(DWS)性能調優系列基礎篇三：衍化至繁之分佈式計劃詳解》。本文後續的討論均基於Stream計劃。分佈式
2. 總體調優思路
經過前面對SQL語句執行流程的介紹，咱們能夠知道，性能瓶頸可能發生在CN端、DN端，以及結果集返回，驅動數據處理等環節，性能調優的第一步就是定位瓶頸點主要發生在哪一個環節。因爲GaussDB DWS大數據量處理時，大部分執行時間消耗在DN端，故本博文主要針對DN端語句執行進行整體調優思路的分享。工具
談到執行性能，其實從數據模型建模、集羣部署、表結構設計，到最終的SQL語句優化，都與之緊密相關，如上圖所示，咱們使用金字塔來描述整個調優過程。越接近塔尖，其對於整個業務性的影響範圍越廣，須要調優時，調優成本也越高，因此在設計之初須要投入足夠精力，從上至下，咱們須要全面的設計，才能減小在最終SQL調優時返工的可能。oop
整個調優過程實際上是一個不斷迭代的過程，如上圖所示。即便設計再嚴密，也有可能出現SQL語句性能的優化須要致使數據建模更改、集羣部署、表分佈鍵調整的狀況，這時一發動全身將引發較高的成本，同時會對其它已經調優完畢的SQL產生影響，致使從新調優，成本較高。性能
咱們統一將前三階段歸結爲靜態調優，將SQL語句級調優歸結爲執行態調優。下面重點來探討執行態調優-SQL語句調優，從調優步驟來看能夠分爲性能瓶頸診斷、性能緣由分析和調優項實施，從調優實施對象來看，可能包括前面提到的數據建模、集羣部署、表結構設計方面的修改，SQL語句層調優能夠分爲系統級調優和語句級調優。固然，有一些調優項，例如系統調優項，能夠做爲經驗固化下來，在集羣部署的時候就一併設置好，減小這方面調優花費的成本。同時，SQL調優也是一個迭代的過程，在實施一次調優項後，須要繼續從新進行調優分析，直至性能達到標準爲止。後面的章節，將圍繞調優步驟和SQL層的調優項來開展。學習
3. 性能瓶頸診斷
GaussDB DWS提供了豐富的計劃信息顯示工具Explain，以及動態執行信息分析工具Top SQL。大數據
Explain工具主要針對單個語句進行展現，可使用explain命令顯示CN生成的SQL語句的計劃，也可使用explain analyze/performance命令顯示執行態信息。經過執行態信息，咱們能夠分析出算子爲單位的性能，也能夠分析出算子內部各步驟的性能，進一步爲診斷性能的瓶頸打下了基礎。Explain工具相關內容請參考博文《GaussDB(DWS)性能調優系列基礎篇二：大道至簡explain計劃信息》。
Top SQL工具則針對集羣中運行的語句進行總體性能分析，其包含12個視圖，能夠將執行時間超過必定設置閾值的語句的執行狀態、執行結果進行實時查詢，同時能夠設置將其轉儲用做後續分析。附加於該工具之上的SQL自診斷調優工具，則經過瓶頸點的分析，給出可能的性能緣由分析。同時，咱們還提供Unique SQL工具，進行一類SQL的性能持續跟蹤，能夠用於發現系統資源及硬件問題對SQL性能產生的影響。Top SQL工具相關內容請參考博文《GaussDB(DWS)性能調優系列實戰篇二：十八般武藝之壞味道SQL識別》。
4. 性能緣由分析
性能緣由分析屬於性能調優裏的高階知識了，一般要對數據庫的執行實現原理有基本瞭解纔可以逐步深刻下去。本章節將深刻淺出地介紹數據庫執行實現原理的基本技術，幫助各位讀者朋友可以有興趣去主動查找性能產生的緣由，從而本身找到性能調優的方法。
前面已經對GaussDB DWS的執行流程進行了介紹，由CN生成執行計劃下發到DN去執行。GaussDB DWS是基於代價來生成計劃的，所以須要依據基表的統計信息，進行每一步結果集統計信息的估算，根據數據規模的場景從GaussDB DWS支持的備選算子中選擇最優的算子組合成計劃進行執行。所以，統計信息是計劃準確的前提，在執行SQL語句前要確保收集最新的統計信息，有關統計信息的收集能夠參見博文《GaussDB(DWS)性能調優系列基礎篇一：萬物之始analyze統計信息》。
因爲統計信息只包含基表的統計信息，表關聯以後的統計信息只能經過估算獲得，所以仍然可能存在估算不許的狀況。GaussDB DWS針對不一樣的SQL語句中的操做，爲每一個操做內部實現了不一樣的算子。每一個算子可能在部分場景下是佔優的，但其它場景比較差。SQL優化時，根據具體的場景去自動匹配最優的算子。若是存在估算不許，將致使算子選擇出現失誤，從而計劃較差，此時就須要根據計劃的瓶頸來分析具體的緣由了。
一般狀況下，GaussDB處理的操做類型主要分爲：掃描算子（Scan）、關聯算子（Join）、彙集算子（Agg）和網絡傳輸算子（Stream）。下表列出了各算子類別的使用場景，以及各種別中可選的算子，及其適用範圍，同時列出調優場景，供你們參考。
（1）掃描算子（Scan）：主要用於處理從存儲掃描數據，返回上層算子，包括：全表掃描算子、索引掃描算子，其中行列存均對應不一樣的全套掃描算子，索引掃描包括：IndexScan（普通索引掃描）、IndexOnlyScan（僅掃描索引便可得到結果）、BitmapScan（須要索引掃描獲取位圖後再到基表上掃描），BitmapScanAnd/Or（從多個索引掃描進行位圖運算後再到基表上掃描），因爲索引掃描的原理基本都相同，故一併探討。
（2）關聯算子（Join）：主要用於處理表的關聯操做。在數據庫中，多表關聯時，SQL優化會選擇關聯順序進行兩兩關聯。表關聯時能夠包含關聯操做，也能夠沒有關聯操做（笛卡爾積）。在GaussDB DWS中，主要包含NestLoop, HashJoin, MergeJoin三種關聯算子。
（3）彙集算子（Agg）：
（4）網絡傳輸算子（Stream）：
（5）其它算子：同時GaussDB DWS還支持排序（Sort）、集合（SetOp）、物化（Materialize）、窗口彙集（WindowAgg）和輸出限制（Limit）算子，因爲調優基本不涉及，故此處略過。
5. 調優項實施
在知道致使性能問題的緣由後，就能夠制定調優項並開始實施了。前面已經提到，調優項實施的範圍很廣。本博文僅探討數據庫級的調優項，包括系統級調優和語句級調優兩部分。
a)系統級調優項
系統級調優又細分爲操做系統參數調優和數據庫全局參數調優，一般涉及到的是系統CPU、IO、內存、網絡資源的充分使用，避免資源衝突，提高整個系統查詢的吞吐量。
因爲數據庫是運行在操做系統之上的，所以操做系統資源的利用率對於數據庫性能的提高起到基石的做用。對於操做系統參數的調優，主要集中在操做系統內存參數、IO參數以及網絡參數的設置上，具體可參見GaussDB DWS產品文檔。
數據庫級別的調優，主要也是集中在上述資源的使用上，在上述四維度有如下主要因素的考慮（具體設置方法能夠參見GaussDB DWS產品文檔）：
b)語句級調優項
語句級調優一般須要經過計劃分析，找到性能瓶頸點，而後根據瓶頸點對應的掃描、關聯、彙集、Stream等算子，分析是否屬於算子適用場景，是否符合調優條件。若是是，咱們有如下調優手段：
i. 經過修改表定義，包括行列存、表的分佈方式，達到減小IO和網絡資源開銷的目的，詳見博文《GaussDB(DWS)性能調優系列實戰篇三：十八般武藝之好味道表定義》。
ii. 若是最終分析是因爲估算不許致使，能夠經過相關GUC參數調整來設置不一樣的結果集估算模型，或禁止生成某種類型的算子，經過改進估算值達到優化計劃的目的，詳見博文《GaussDB(DWS)性能調優系列實戰篇五：十八般武藝之路徑干預》。
iii.若是在遷移或升級過程當中出現計劃劣化，也能夠經過Plan Hint的調優方式干預優化器生成理想的計劃，詳見博文《GaussDB(DWS)性能調優系列實戰篇六：十八般武藝Plan hint運用》。
iv.對於上述調優手段都沒法解決的問題，例如：下推問題，相關子查詢提高，NOT IN等問題，或者SQL語句存在計算冗餘等問題，須要根據瓶頸點選擇靈活多變的SQL改寫策略消除瓶頸點，具體可參見博文《GaussDB(DWS)性能調優系列實戰篇四：十八般武藝之SQL改寫》
總的來講，性能調優是一項艱鉅的工程，固然深刻其中，學習到的知識以及得到的收穫都是很是大的。後續論壇也會推出更多的博文對性能調優的方方面面進行介紹，幫助各位讀者迅速積累調優的經驗。