本文介紹AnalyticDB for MySQL中性能調優的常見問題及解決方法。
當常見問題場景中未明確產品系列時，表明該問題僅適用于AnalyticDB for MySQL數倉版。
常見問題概覽
為什么寫入峰值下降了，但是CPU沒有降下來？
AnalyticDB for MySQL會對寫入的數據實時地構建索引，以加速查詢。構建索引需要消耗一定的系統資源，特別是在有寫入峰值導致寫入量暴增時，索引構建過程更加占用資源。
在哪些場景下，AnalyticDB for MySQL的查詢性能比較慢？
AnalyticDB for MySQL做為分布式系統，其優勢在于利用多機并行的能力，提升海量數據的處理速度，適合大數據量的分析。在某些場景中，查詢計算量不是特別大，AnalyticDB for MySQL具備分布式開銷，反而查詢較慢。也有某些場景下，AnalyticDB for MySQL單機版集群可以更好利用存儲的索引來提升查詢性能。
如何解決查詢內存超限？
AnalyticDB for MySQL中查詢內存限制都是為了保證整個集群的穩定性，避免某些慢SQL查詢導致集群崩潰。關于慢SQL查詢排查分析，請參見典型慢查詢，重點關注峰值內存和掃描量。
下表匯總了查詢超限的錯誤碼及對應異常和處理辦法。
ErrorCode | 異常原因 | 處理辦法 |
CLUSTER_OUT_OF_MEMORY(32001) | 集群當時內存消耗整體比較大，為了保持系統整體的穩定性，會選擇斷開一個內存使用特別大的查詢連接，以免影響其他查詢的正常運行。 |
|
EXCEEDED_MEMORY_LIMIT(32003) | 當前查詢的內存使用消耗超過內存限制。 | 建議結合SQL排查該Query消耗內存大的算子。 |
OUT_OF_PHYSICAL_MEMORY_ERROR(33015) | 當前Query運行時超過內部計算內存池限制。 | 可以排查出現問題的階段，有沒有峰值內存和掃描量比較高的查詢，并分析查詢內存高的原因。 |
查詢過程中報磁盤超出限制是什么原因，應該怎么處理？
當AnalyticDB for MySQL集群為彈性模式時，查詢有可能會使用batch模式，查詢會把查詢的中間結果寫入磁盤，這時候如果中間結果集較大，就有可能觸發磁盤空間超出限制的情況。
ErrorCode | 異常原因 | 處理辦法 |
OUT_OF_SPILL_SPACE(32007) | 當前落盤大小超過磁盤的限制，磁盤沒有足夠空間落盤。 | 磁盤超出限制是因為使用BSP模型運行Batch類型查詢任務，大量的數據Shuffle和算子狀態落盤導致磁盤空間不足、超出使用限制。需要關注采用BSP模型運行的Batch類型查詢任務的峰值內存、數據掃描量和數據Shuffle量，并且適當減少此類查詢的并發數量。如果集群規格比較大（計算節點多于32臺），可以將 |
EXCEEDED_SPILL_LIMIT(32006) |
如何定位查詢突然變慢的原因？
同一個SQL Pattern的查詢變慢，可能有如下原因：
相同條件下某些表的數據量增加導致處理的數據量增加，最終導致查詢變慢。
查詢條件有變化，例如掃描的二級分區數增多，或者查詢范圍增加。
系統壓力增加。可能是寫入量增加占用了較多系統資源，影響了查詢性能，也可能是有Bad SQL的存在占用了較多系統資源。
您可以單擊目標SQL Pattern操作列的查看詳情查看不同的SQL Pattern在正常情況下的資源消耗，例如執行次數、查詢耗時、執行耗時、掃描量以及峰值內存等指標。詳細信息，請參見SQL Pattern。
如何定位大內存查詢和占用CPU較高的查詢？
更多詳情，請參見典型慢查詢。
ANALYZE命令為什么會被診斷為慢查詢？
系統在運維時間自動發起的ANALYZE命令會低優先級執行（IO限流+CPU低優先級），因此執行緩慢，耗時很長，會被診斷為慢查詢，一般不會影響業務。如果CPU負載不高，或者CPU負載高與運維時間沒有明顯聯系，可以忽略該問題。如果CPU負載持續很高，請參考下文CPU負載過高，查詢響應時間受到影響如何處理。
使用統計信息功能過程中，CPU負載過高的原因？
導致CPU負載過高的原因有如下兩點：
在默認的運維時間04:00-05:00，系統會對表進行全量掃描，收集每列的統計信息，在該時段CPU負載過高。
大部分統計信息是增量收集的，一般資源消耗不會太高。由于統計信息功能是在集群內核版本為3.1.6及以上版本的AnalyticDB for MySQL數倉版集群才默認開啟的，所以當集群內核版本從3.1.6以下版本升級到3.1.6及以上版本時，會觸發一次全量數據的統計信息收集，導致集群內核版本完成升級后的一段時間內統計信息收集的工作量較大，CPU負載較高，完成收集后即可緩解。
當CPU負載過高時，需要判斷查詢響應時間是否受影響。如果平均查詢響應時間沒有明顯變化，說明查詢響應時間未受到影響。因為ANALYZE命令是在CPU低優先級和IO限流下緩慢執行，用戶本身的查詢不一定會受影響，即使監控項中顯示CPU負載高，但有查詢任務時，資源會優先服務查詢任務。
統計信息收集任務導致CPU負載過高，查詢響應時間受到影響如何處理？
當查詢響應時間受到影響時，依次參考以下方案處理：
調整運維時間到業務低峰期。
set adb_config O_CBO_MAINTENANCE_WINDOW_DURATION = [04:00-05:00];如果無法評估合適的低峰期，可以適當下調系統查詢IO限制，默認50 MB，調整時建議不低于16 MB。
set adb_config CSTORE_IO_LIMIT_SYSTEM_QUERY_BPS = 52428800;將統計信息收集工作劃分到指定的資源組，如低優先級資源組，來隔離負載。詳情請參見自動收集統計信息。
set adb_config O_CBO_AUTONOMOUS_STATS_ACCOUNT = [user_name];上調列的過期比例，以減少收集工作量。列的過期比例默認為0.1（10%），取值范圍（0,1），建議上調值不超過0.5。
set adb_config O_CBO_STATS_EXPIRED_RATIO = 0.1;
如果以上方案均不能解決問題，可以嘗試關閉統計信息自治功能（set adb_config O_CBO_AUTONOMOUS_STATS_ENABLED=false;） 。但是關閉自動收集統計信息后，可能會出現查詢性能回退。后續如果需要統計信息，需要您手動維護。詳情請參見手動收集統計信息。
通過SELECT * FROM INFORMATION_SCHEMA.COLUMN_STATISTICS查詢統計信息，為什么統計信息多天未更新？
統計信息不更新的原因有如下兩點：
表的統計信息未過期。
統計信息默認過期比例是0.1（10%），即數據變化量（Update、Delete、Insert或Replace）需要超過10%才會更新。如果數據變化量不大，可以再觀察一周繼續正常使用即可。
表和列太多且數據量大。
默認情況下，排除增量更新，一天只有1小時的收集時間。如果表和列很多，一天內無法全部更新，可能需要經過一周才能更新一次。如果表和列較多，如超1000列，并且統計信息更新時間在一周內，統計信息多天未更新屬于正常現象，繼續觀察使用即可。
新建的表導入數據會自動更新統計信息嗎？
通過INSERT OVERWRITE批量導入方式，數據導入完成后會立即自動收集基礎統計信息。通過INSERT INTO、REPLACE INTO等實時導入方式導入數據，需要等到運維時間，或者Build完成后的增量收集周期時間觸發增量收集任務，建議您在導入數據后手動收集一次基礎統計信息。詳情請參見手動收集統計信息。