本文介紹AnalyticDB MySQL版中幾種典型的慢查詢以及導致慢查詢的原因。
消耗記憶體的慢查詢
查詢的峰值記憶體（Peak Memory）可以協助您評估記憶體的消耗情況。通常來說，查詢峰值記憶體越大，記憶體消耗越大。
您可以通過SQL診斷功能來檢索某個時間段內執行耗時較長的查詢，然後在查詢屬性或不同層級的診斷結果中查看目標查詢的峰值內存。更多詳情，請參見查看查詢屬性與診斷結果。
- Stage中有GROUP BY操作。
AnalyticDB MySQL會將GROUP BY欄位的值緩衝在記憶體中。如果GROUP BY的欄位唯一值較多，就會佔用較多記憶體。
- Stage中有JOIN操作。
在使用Hash方式進行Join時，AnalyticDB MySQL會把某張表的資料緩衝到記憶體中。如果被緩衝的表較大，就會佔用較多記憶體。
- Stage中有SORT操作。
在執行資料排序時，AnalyticDB MySQL會把資料緩衝到記憶體中。如果需要排序的資料量較大，就會佔用較多記憶體。
- Stage中有視窗函數操作。
在執行視窗函數時，AnalyticDB MySQL會把資料緩衝在記憶體中。如果需要執行視窗函數的資料量較大，就會佔用較多記憶體。關於視窗函數的詳情，請參見視窗函數。
消耗CPU的慢查詢
查詢的執行耗時（Time Consumed）可以協助您評估CPU的消耗情況。通常來說，查詢執行耗時越長，CPU消耗越大。
您可以通過SQL診斷功能來檢索某個時間段內執行耗時較長的查詢，然後在查詢屬性中查看目標查詢的耗時。更多詳情，請參見查看查詢屬性。
- 過濾條件沒有下推到儲存層。AnalyticDB MySQL在建立表時預設為所有欄位建立了索引，使用索引進行過濾可以極大減少CPU資源的消耗，但是在某些情境下過濾條件沒有下推。更多詳情，請參見過濾條件沒有下推。
- Join條件中帶有過濾操作。如果Join中帶有過濾條件，AnalyticDB MySQL會先對兩表執行Join，再對Join後的資料執行過濾，此時的過濾無法使用索引。如果Join後產生的資料量較大，過濾操作就會消耗較大的CPU資源。
- Join時沒有指定Join條件。如果沒有指定Join條件，AnalyticDB MySQL會對左右兩表執行笛卡爾積運算，產生的資料量行數是左右兩表資料行數的乘積，該類操作會導致消耗較大的CPU資源。
消耗磁碟I/O的慢查詢
查詢的掃描行數（Scanned Rows）和掃描量（Amount of Scanned Data）可以協助您評估磁碟I/O資源的消耗情況。通常來說，掃描行數和掃描量越多，磁碟I/O消耗越大。
您可以通過SQL診斷功能來檢索某個時間段內執行耗時較長的查詢，然後在查詢屬性或不同層級的診斷結果中查看目標查詢的掃描行數和掃描量。更多詳情，請參見查看查詢屬性與診斷結果。
- 過濾條件的資料篩選率較低，導致索引的使用效率不高，需要讀取的索引量較大。
- 過濾條件沒有下推，導致對源表進行了全表掃描。
- 過濾條件下推，但是過濾條件設定的範圍較大，仍然有大量資料被掃描。
- 需要掃描的分區較多。通常情況下，分區越多意味著需要掃描的資料量越大。