摘要： 性能調優是應用遷移或開發過程中的關鍵步驟，同時也在整個項目實施過程中占據很大的份量，本篇主要介紹數據庫級別的性能調優思路和總體策略。
性能調優是應用遷移或開發過程中的關鍵步驟，同時也在整個項目實施過程中占據很大的份量，在很多實施步驟中都需要進行考慮，從開始的數據建模，表定義的設計，到數據庫硬件、集群部署的選擇，再到數據庫系統級調優、數據表結構設計，以及單個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調優時返工的可能。
整個調優過程其實是一個不斷迭代的過程，如上圖所示。即使設計再嚴密，也有可能出現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改寫》
總的來說，性能調優是一項艱巨的工程，當然深入其中，學習到的知識以及獲得的收獲都是非常大的。后續論壇也會推出更多的博文對性能調優的方方面面進行介紹，幫助各位讀者迅速積累調優的經驗。