AnalyticDB：運算元層級診斷結果

彙總運算元的彙總度一般指GROUP BY分組彙總操作中的輸入資料量和輸出資料量的比值（即InputDataSize和OutputDataSize的比值），該值越小表明彙總度越低，彙總效果越差。在AnalyticDB MySQL版中，分組彙總操作一般分為兩步：初步彙總（PARTIAL）和最終彙總（FINAL）。如果彙總運算元分組的個數較多，會導致彙總度低，那麼在第一步的初步彙總操作中，不但不能減少網路資料轉送，反而會消耗大量的計算資源。

可以考慮跳過初步彙總操作，直接在各個節點間對資料進行重分布，之後直接進行一次最終彙總。更多詳情，請參見分組彙總查詢最佳化。

• 如果是查詢語句使用了Hint或叢集使用了配置，導致的過濾條件下推功能關閉，請檢查使用該Hint或配置的原因並判斷是否可以取消該Hint或配置。更多詳情，請參見過濾條件不下推。
• 如果是使用了函數，可以考慮是否直接使用該函數寫入資料，而在查詢時去掉函數。
• 如果是過濾條件中的相關欄位沒有索引導致過濾條件沒有下推，那麼需要檢查沒有索引的原因。

Join的資料膨脹率是Join的輸出行數與Join的輸入行數的比值，其中Join的輸入行數為左錶行數與右錶行數之和。對於合理Join條件，一般Join的輸出行數會小於輸入行數，如果Join的輸出行數大於輸入行數，那麼會存在Join資料膨脹的問題，Join資料膨脹會導致較多的計算資源和記憶體資源被佔用，導致查詢較慢。

• 如果是資料本身特徵導致的Join資料膨脹，例如左右表都大量存在的相同的值，可以考慮在表過濾階段將這些相同值都過濾掉不參與Join。
• 如果是不優的Join順序導致的資料膨脹，可以考慮手動調整Join順序。調整方法，請參見手動調整Join順序。

建議將Left Join最佳化改寫成Right Join。改寫方法，請參見Left Join最佳化改寫為Right Join。

Cross Join，即沒有Join條件的Join操作，輸出的行數是左右兩錶行數的乘積。如果左右表都較大，會極大地影響AnalyticDB MySQL版叢集的穩定性。

考慮增加Join條件，消除Cross Join。

掃描運算元會在AnalyticDB MySQL版的儲存層進行資料的過濾和詳細資料的讀取，如果SELECT的欄位個數較多，需要讀取的詳細資料也較多，那麼就會佔用較大的磁碟I/O資源，影響AnalyticDB MySQL版叢集整體穩定性。

可以最佳化SQL語句，減少SELECT語句中不必要的欄位。

AnalyticDB MySQL版是分布式執行架構，大表的資料一般需要指定分布欄位，資料寫入時根據分布欄位分散到不同的儲存節點上。如果分布欄位的值分布不均勻，那麼資料存放區在各個節點上時也會不均勻，最終導致資料讀取時，各個節點在讀取資料時存在時間上的長尾，影響最終的查詢效果。

通過選擇合適的分布欄位來減少表掃描資料量的傾斜。最佳化方法，請參見資料建模診斷。

AnalyticDB MySQL版在使用索引進行資料過濾時，若需要過濾的欄位過濾度（即過濾運算元的輸出資料量和輸入資料量的比值）較低時，使用索引不一定能獲得預期的過濾效果。

可以考慮不下推過濾條件，而在計算節點中直接執行過濾操作。更多詳情，請參見過濾條件不下推。