摘要：本文重點介紹單個SQL陳述句持續執行慢的場景，
本文分享自華為云社區《GaussDB(DWS) SQL性能問題案例集》，作者：黎明的風，
本文重點介紹單個SQL陳述句持續執行慢的場景，我們可以對執行慢的SQL進行單獨分析，SELECT、INSERT、UPDATE等陳述句都可以使用explain verbose + SQL陳述句輸出查詢計劃來進行分析，這樣只輸出查詢計劃，陳述句不會被實際的執行，
如果查詢計劃只出現__REMOTE_FQS_QUERY__或__REMOTE_LIGHT_QUERY__，看不到具體的計劃，可以先執行set enable_fast_query_shipping to off; 然后再重新列印執行計劃，
經常遇到的問題有以下幾個：
【案例1】陳述句中包含不下推的函式
檢查查詢計劃中是否包含_REMOTE_TABLE_QUERY_關鍵字， 如果有則表示陳述句沒有下推，資料需要從DN上收取到CN上，然后陳述句在CN上執行，陳述句不下推原因，要從CN的日志中查找，搜索的關鍵字為：SQL can’t be shipped，以下為函式造成的不下推例子：
LOG: SQL can't be shipped, reason: Function Fun1() can not be shipped
此外如果出現以下幾種不下推的關鍵字：__REMOTE_GROUP_QUERY__、__REMOTE_LIMIT_QUERY__、
__REMOTE_SORT_QUERY__，這種需要檢查enable_stream_operator引數是否處于關閉狀態，一般來說打開STREAM開關后，陳述句就可以下推執行了，
如果出現以下兩種關鍵字，表示陳述句可以下推執行：
__REMOTE_FQS_QUERY__：表明陳述句走了Fast Query Shipping（FQS），SQL陳述句會下發到DN上執行，并且各DN之間沒有資料互動，常見的場景有過濾條件為等值查詢（where id = 1），或者關聯的列是表的分布列的查詢（where t1.id = t2.id），
__REMOTE_LIGHT_QUERY__：表明陳述句走了Light Proxy（CN輕量化），將陳述句下發給了單個DN去處理，常見的場景過濾條件是分布列的等值查詢（where id = 1），或者向一個DN插入資料的INSERT陳述句，
【案例2】表上有索引但沒有走索引掃描，進行了全表掃描
從查詢計劃中可以看到Seq Scan或CStore Scan這樣的關鍵字，如下所示：
對于行存表：-> Seq Scan on t1
對于列存表：-> CStore Scan on col_t1
出現這種問題通常有以下幾種情況：
沒有對所查詢的表收集統計資訊
如果表的實際行數很大，而估算行數很小，查詢時可能會走全表順序掃描，造成執行速度慢，此時通過analyze表更新統計資訊，讓優化器選擇最佳的查詢計劃，一般就可以解決執行慢的問題，
【案例3】模糊匹配沒有走索引
后模糊匹配查詢可以通過建立一個BTREE索引來實作，需要根據資料型別設定索引的operator，對于text，varchar和char分別設定和text_pattern_ops，varchar_pattern_ops和bpchar_pattern_ops，
例如c1列的型別為text，創建索引時增加text_pattern_ops，
CREATE INDEX ON t1 (c1 text_pattern_ops);
創建索引后，可以看到陳述句執行時會使用到前面創建的索引，執行速度會變快，
【案例4】創建索引時所指定列的順序問題
多列復合索引的組織結構與單列欄位索引結構類似，按索引內運算式指定的順序編排，當創建多列復合索引時，選擇什么樣的列的順序，對查詢性能會帶來一定的影響，
例如按照c_date，c1和c2列的順序建立檢索，如果符合c_date條件的資料很多，通過這個索引掃描的資料就很會很多，造成執行時間長，
新建多列復合索引，將查詢條件里的等值條件的列放到索引列的前面，先使用等值進行過濾，需要掃描的資料變少，查詢變快，
【案例5】磁區表沒有磁區剪枝進行了全表掃描
問題背景：XSYX局點使用MERGE INTO陳述句將每天的資料入庫到表里，目標表為磁區表，業務上線運行一段時間后發現MERGE INTO速度逐漸變慢，
原因分析：MERGE INTO陳述句的源表和目標表都是磁區表，當前僅對源表增加了時間的過濾條件，可以進行磁區剪枝，目標表由于沒有指定時間過濾條件，進行的是全表掃描，隨著每日的入庫業務運行，目標表的資料量越來越大，造成執行速度越來越慢，
解決方案：由于源表的資料在MERGE INTO時會匯入到目標表的對應磁區里，可以對目標表增加時間的過濾條件進行磁區剪枝，
業務修改前的查詢計劃：
對目標表增加了時間過濾條件后的計劃顯示可以走磁區剪枝：
【案例6】表資料在DN節點上有存盤傾斜
從查詢計劃中的A-time可以看到最長和最短的執行時間相差很大，說明在不同DN上掃描資料的時間不同，
在查詢計劃的DN資訊中，通過rows可以看出在datanode1上掃描的資料量明顯多于datanode2，說明有存盤傾斜，這種情況建議對表進行合理的設計，選擇合適的分布列，將資料均勻分布到所有的DN上，
【案例7】自定義函式引起執行慢
問題現象：查詢陳述句比較簡單，兩個表做關聯后輸出了其中一列的值，在輸出前增加了一個自定義函式對資料進行了處理，
原因分析：自定義函式里邏輯相對復雜，包含了對表的查詢及資料計算邏輯，造成執行變慢，
解決方案；業務上對自定義函式進行性能優化，
【案例8】查詢視圖執行時間長
問題現象：某YD局點從C80版本遷移資料到8.1.1版本后，查詢PG_STAT_USER_TABLES視圖的時間由幾分鐘變成半個小時都不出結果，
原因分析：8.1.1版本中的PG_STAT_USER_TABLES視圖在獲取插入、更新、洗掉的行數的欄位數值時，每一條記錄都涉及到CN和DN的互動，在資料量和集群規模大的情況下耗時較多，
解決方案：建議根據應用的實際需要，將視圖定義中不需要的函式注釋掉以提升查詢效率，
【案例9】關閉indexscan和bitmapscan后可以使用并行提升性能
問題現象： 查詢計劃中顯示走了Index Scan，通過索引查詢出的資料量比較大，速度慢，
原因分析：由于使用索引掃描時無法使用并行查詢，當索引訪問的資料量大時執行速度較慢，
解決方案：將enable_indexscan和enable_bitmapscan引數關閉，設定query_dop后走并行查詢，
點擊關注，第一時間了解華為云新鮮技術~
轉載請註明出處，本文鏈接：https://www.uj5u.com/shujuku/514133.html
標籤：SQL Server