AnalyticDB MySQL版的SQL診斷功能可以對SQL查詢進行Query、Stage和算子（Operator）級別的信息統(tǒng)計，再在統(tǒng)計信息的基礎(chǔ)上進行診斷并提供調(diào)優(yōu)建議。本文介紹如何查看和分析Stage級別診斷結(jié)果。

診斷結(jié)果類型

說明 查看Stage級別診斷結(jié)果的方法，請參見查看診斷結(jié)果。

較大的數(shù)據(jù)量被廣播

  • 問題

    廣播（Broadcast）是在兩個相鄰的Stage間，上游向下游Stage傳輸數(shù)據(jù)時所用的一種方法（更多詳情，請參見數(shù)據(jù)輸出類型）。如果某個Stage廣播了較多數(shù)據(jù)，可能會導致查詢占用較大的峰值內(nèi)存。

  • 建議
    • 首先需要判斷當前的廣播操作是否合理。某個Stage中的數(shù)據(jù)被廣播，一般是因為這些廣播后的數(shù)據(jù)會作為Join操作的右表（Builder端）來在內(nèi)存中構(gòu)建哈希表，所以右表越小越好。在高并發(fā)查詢的場景下，這樣有利于減少節(jié)點間的網(wǎng)絡(luò)連接，提升系統(tǒng)整體穩(wěn)定性。對于Join條件存在數(shù)據(jù)傾斜的場景，如果不廣播小表，那么會出現(xiàn)如下圖的執(zhí)行流程：1

      假設(shè)上圖中的表Tsmall在b字段上存在嚴重數(shù)據(jù)傾斜，那么當表Tbig以a字段均勻地分布在AnalyticDB MySQL版的存儲節(jié)點上時，對Tbig表的重分布會存在處理時間長尾，而且在下游Stage執(zhí)行Join時也會存在長尾。

      如果Tbig表不做重分布，而只廣播Tsmall表，會有如下的執(zhí)行流程：2

      如上圖所示，只廣播Tsmall這張小表，可以緩解數(shù)據(jù)傾斜帶來的處理長尾問題。

    • 在某些場景下，例如統(tǒng)計信息過期，會導致預估的表大小有偏差，從而導致廣播了大量數(shù)據(jù)，此時可以考慮使用HintJOIN_DISTRIBUTION_TYPE=repartitioned來關(guān)閉數(shù)據(jù)的廣播功能。

Stage輸入數(shù)據(jù)傾斜

  • 問題
    導致Stage輸入數(shù)據(jù)傾斜的可能原因如下：
    • 建表時選擇的分布字段不合理，導致Stage中的某個數(shù)據(jù)掃描算子在掃描數(shù)據(jù)時存在傾斜。
    • 上游Stage的數(shù)據(jù)通過網(wǎng)絡(luò)傳輸?shù)疆斍癝tage時存在傾斜。
  • 建議

Stage輸出數(shù)據(jù)傾斜

  • 問題

    Stage輸出數(shù)據(jù)傾斜會導致當前Stage處理耗時不均勻，存在長尾；如果下游Stage處理過程復雜，也會導致下游Stage在處理數(shù)據(jù)時存在長尾，最終都會影響查詢整體性能。

  • 建議

    通過診斷結(jié)果中提示的字段名來判斷是否是這些字段存在數(shù)據(jù)傾斜（如出現(xiàn)大量空值）。