為什么DWS使用一段時間后執行SQL很慢？
數據庫在使用一段時間后，隨著業務的增加促使表數據增加，或者對表數據經常進行增、刪、改過后，引發數據膨脹和統計信息不準造成性能下降。
建議對于頻繁增、刪、改的表，定期做vacuum full和analyze操作。操作步驟如下：
1.默認每30000條數據收集100條做統計信息，當數據量大的時候，發現sql時快時慢，一般是執行計劃發生了變化，統計信息的需要調整采樣率。set default_statistics_target 可以提高采樣率，對優化器生成最優計劃有所幫助。
2.重新analyze。詳細信息請參見《數據倉庫服務用戶開發指南》的“ANALYZE | ANALYSE”章節。
說明若用戶想要知道是否是磁盤碎片的問題影響了數據庫的性能，可以使用以下函數進行查詢：
select * from pgxc_get_stat_dirty_tables(30,100000);
為什么DWS的性能在極端場景下并未比單機數據庫好
DWS 中由于MPP架構的限制導致少部分PG系統方法、函數無法下推到DN節點來執行，僅能在CN端出現性能瓶頸。
原理解釋
- 一個操作能夠并行執行是有條件的，需要邏輯上能夠并行，比如做匯總（SUM），我們可以各個節點（DN）并行匯總后，最后的匯總一定是不能并行，要在某一個節點（CN）上執行，由于大部分的匯總工作已經在DN節點完成，CN端的工作是比較輕量的。
- 某些場景必須要集中執行，比如事務號，必須要保證全局唯一，這個任務在我們系統里是通過GTM來實現的，因此，GTM也是全局唯一的組件（主備）。所有需要全局唯一的任務DWS 都是通過GTM來完成，只是在設計上盡量避免阻塞在GTM上，因此GTM并沒有太多瓶頸，而且有些場景下還可以GTM-Free和GTM-Lite。
- 從傳統單機數據庫的應用開發模式到并行數據庫，為確保獲得更好的性能，可能需要對業務進行少量改動，尤其是傳統Oracle的存儲過程互相嵌套的開發模式，如果要保證高性能，需要進行業務修改及對應的適配。
解決方案
- 如遇到此類問題，請參考《數據倉庫服務數據庫開發指南》中的“優化查詢性能”章節。
- 或者，請聯系技術人員進行業務適配的修改調優。
業務讀寫阻塞，如何查看某個時間段的sql執行記錄？
當您的數據庫集群出現讀寫阻塞時，可通過TopSQL功能查看某個時間段所執行的sql語句，支持查看當前CN或者所有CN的sql語句。
TopSQL功能包括查看實時sql語句和歷史sql語句：
- 實時sql語句查詢請參見：《數據倉庫服務開發指南》的“實時TopSQL”章節。
- 歷史sql語句查詢請參見：《數據倉庫服務開發指南》的“歷史TopSQL”章節。
DWS中“算子下盤”是什么含義？
用戶業務查詢執行過程中，當集群內存不足時，數據庫可能會選擇將臨時結果暫存到磁盤。當臨時結果的磁盤存儲量超過一定值后，用戶會收到告警“查詢語句觸發下盤量超閾值”，那這個告警中的“下盤量”或者經常數據庫中經常出現的“算子下盤”如何理解呢？
算子下盤的概念
任何計算都需要耗費內存空間，差別在于多少而已，對于如果耗費內存過多，會導致其他作業運行內存空間不足，導致作業不穩定，因此我們需要對查詢語句的作業內存使用進行限制，保證作業運行的穩定性。
假如作業想要使用500M內存，但實際上因為內存限制最終只分配到300M內存，則需要把臨時不用的數據寫到磁盤上，內存中只保留正在使用的數據，這就是中間數據落盤的由來。當發生中間數據落盤時，稱之為 算子下盤 。算子落盤空間太大除了會對查詢性能有較大影響，還有可能導致數據庫只讀甚至磁盤滿，因此DWS提供了用戶算子空間限制，可以限制用戶算子落盤的大小，在超限時查詢報錯退出。
哪些算子會發生下盤
當前DWS可下盤算子有六類（向量化及非向量化共10種）：Hash(VecHashJoin)，Agg(VecAgg)，Sort(VecSort)，Material(VecMaterial)， SetOp(VecSetOp)，WindowAgg(VecWindowAgg)。
哪些參數可以控制下盤
- work_mem：可以判斷執行作業可下盤算子是否已使用內存量觸發下盤點，當內存使用超過該參數后將觸發算子下盤。該參數僅在非內存自適應場景（enable_dynamic_workload=off）時生效。work_mem參數設置通常是一個權衡，即要保證并發的吞吐量，又要保證單查詢作業的性能，故需要根據實際執行情況（結合Explain Performance輸出）進行調優。
- temp_file_limit：可以限制落盤算子的落盤文件大小，一般建議根據實際情況設置，防止下盤文件將磁盤空間占滿，超過該值將報錯退出。
如何判斷語句是否發生了下盤
- 通過下盤文件確認：下盤文件位于實例目錄的base/pgsql_tmp目錄下，下盤文件以pgsql_tmp**queryid_**pid命名，可以根據queryid確認是哪條sql發生了下盤。
- 根據等待視圖（pgxc_thread_wait_status）確認：等待視圖中，當出現write file時，表示發生了中間結果下盤。
- 根據執行計劃確認（explain performance）：performance中出現spill、written disk、temp file num等關鍵字時，說明對應的算子出現了下盤。
- 根據topsql確認（前提：topsql功能已開啟）：實時topsql或歷史topsql中，spill_info字段中會包含下盤信息，如果該字段不為空，說明有DN實例出現了下盤。
如何避免下盤
發生算子下盤時，算子運算數據將寫入磁盤，由于磁盤操作相對內存訪問緩慢導致性能下降，查詢響應時間出現極大劣化，因此應盡可能避免查詢執行過程中的算子下盤，建議使用以下方法：
- 減小中間結果集：發生下盤時往往是由于中間結果集過大，因此可以增加過濾條件減少中間結果集大小。
- 避免數據傾斜：數據傾斜嚴重時會導致單DN上數據量過大，引起單DN下盤。
- 及時analyze：當統計信息不準時，行數估算可能偏小，導致計劃選擇非最優，從而出現下盤。
- 單點調優：對業務sql進行單點調優。
- 非內存自適應場景下，當中間結果集無法減少時，應根據實際情況適當調大work_mem參數。
- 內存自適應場景下，內存使用配置要使得數據庫可用內存盡量增大，減少下盤概率。
