AnalyticDB MySQL版集群支持多種規格（更多詳情，請參見規格），不同集群規格的CPU核數、內存大小和數據存儲介質等屬性不同，處理子任務的能力也就不同，因此您需要結合業務查詢特征來選擇集群規格。例如，以Join或分組聚合為主的業務查詢會消耗較多的CPU和內存資源；而以掃描數據和簡單分組聚合操作為主的查詢則會消耗較多的磁盤I/O資源。資源類型消耗量的不同會導致不同規格的集群存在不同的性能瓶頸，最終影響整體的查詢效果。

AnalyticDB MySQL版使用了分布式數據處理架構，一條查詢會被分解成多個Stage在不同的節點上并行執行。所以如果集群中的節點數量越多，AnalyticDB MySQL版處理查詢的能力也會越強。您可以根據實際的業務需求來決定集群節點的購買數量，更多詳情，請參見創建集群。

由于使用了分布式數據處理架構，AnalyticDB MySQL版具備將一條查詢分解到多個節點上并行執行的能力。但AnalyticDB MySQL版能否充分利用多節點來并行處理查詢，還取決于數據在存儲節點上的分布特征。如果數據能夠均勻分布在存儲節點上，那么AnalyticDB MySQL版中的多個子任務在處理數據時，就能幾乎同時結束任務，實現理想的查詢處理；如果數據分布不均勻，那么子任務在處理數據時會存在時間上的長尾，從而影響最終的查詢效果。

AnalyticDB MySQL版在處理查詢時，通常不會將處理過程中的臨時結果暫時寫到磁盤里，而是盡量在內存中將所有數據處理掉。如果查詢需要處理的數據量較大，就可能會長時間占用大量的資源，導致整體查詢效率降低，進而影響最終的查詢效果。

此外，如果AnalyticDB MySQL版中表存儲的數據量較大，那么在執行索引過濾、明細數據讀取等操作時也會出現相互爭搶磁盤I/O資源的情況，導致查詢變慢。

由于集群規格和規模的限制，AnalyticDB MySQL版能同時處理的查詢數量也會存在上限。如果查詢的并發度過高，集群節點資源已到達瓶頸，那么后臺的查詢就會出現較長時間的排隊，影響整體查詢效果。

查詢的復雜度不同，對AnalyticDB MySQL版造成的壓力也不同。例如，如果查詢中過濾條件過于復雜，會在數據過濾時對存儲節點造成一定壓力；如果查詢中Join算子過多，數據可能需要在不同節點間進行多次的網絡傳輸，造成網絡阻塞；如果查詢中分組字段過多，也會占用較多的內存資源。