雲原生資料倉儲AnalyticDB MySQL版提供的多種資料匯入方法，滿足不同情境下的資料匯入需求。然而資料匯入效能依然受各種各樣的因素影響，如表的建模不合理導致長尾、匯入配置低無法有效利用資源等。本文介紹不同情境下的資料匯入調優方法。
通用外表匯入資料調優
檢查分布鍵
分布鍵決定著資料匯入的一級分區，每個表在匯入時以一級分區為粒度並發匯入。當資料分布不均勻時，匯入資料較多的一級分區將成為長尾節點，影響整個匯入任務的效能，因此要求匯入時資料均勻分布。如何選擇分布鍵，請參見選擇分布鍵。
判斷分布鍵合理性：
匯入前，根據匯入資料所選分布鍵的業務意義判斷是否合理。以表Lineitem為例，當選擇l_discount列為分布鍵，訂單折扣值區分度很低，僅有11個不同值，l_discount值相同的資料會分布到同一分區，造成嚴重傾斜，匯入會有長尾，影響效能。選擇l_orderkey列則更為合適，訂單ID互不相同，資料分布相對較為均勻。
匯入後，資料建模診斷中如有分布欄位傾斜，則說明選擇的分布鍵不均勻。如何查看分布鍵診斷資訊，請參見資料建模診斷。
檢查分區鍵
INSERT OVERWRITE SELECT匯入資料的基本特性為分區覆蓋，即匯入的二級分區會覆蓋原表的同名二級分區。每個一級分區內的資料會再按二級分區定義匯入各個二級分區。匯入時需要避免一次性匯入過多二級分區，多個二級分區同時匯入可能引入外排序過程，影響匯入效能。如何選擇分區鍵，請參見選擇分區鍵。
判斷分區鍵合理性：
匯入前，根據業務資料需求及資料分布判斷分區鍵是否合理。如Lineitem表按l_shipdate列做二級分區，資料範圍橫跨7年，按年做分區有7個分區，按日做分區有2000多個分區，單分區約3000萬條記錄，選擇按月或者按年做分區則更合適。
匯入後，資料建模診斷中如有不合理的二級分區，則選擇的分區鍵不合適。如何查看分區鍵診斷資訊，請參見分區欄位的合理性診斷。
檢查索引
AnalyticDB MySQL建表時預設全列索引，而構建寬表的全列索引會消耗部分資源。匯入資料到寬表時，建議使用主鍵索引。主鍵索引用於去重，主鍵列數過多影響去重效能。如何選擇主鍵索引，請參見選擇主鍵。
判斷索引合理性：
離線匯入情境通常已經通過離線計算進行去重，無需指定主鍵索引。
在頁簽，查看錶資料量、索引資料量和主鍵索引資料量。當索引資料量超過表資料量時，需要檢查表中是否有較長的字串列，這種索引列不僅構建耗時，還佔用儲存空間，可以刪除索引，請參見ALTER TABLE。
說明主鍵索引無法刪除。需要重建表。
增加Hint加速匯入
在匯入任務前增加Hint（direct_batch_load=true）可以加速匯入任務。
該Hint僅數倉版彈性模式叢集3.1.5版本支援，若使用後匯入效能無明顯提升，請提交工單。
樣本如下：
SUBMIT JOB /*+ direct_batch_load=true*/INSERT OVERWRITE adb_table
SELECT * FROM adb_external_table;使用彈性匯入功能加速匯入
僅核心版本3.1.10.0及以上的叢集支援使用彈性匯入功能。
已建立Job型資源群組的企業版及湖倉版叢集支援使用彈性匯入功能。
彈性匯入僅支援匯入MaxCompute資料和以CSV、Parquet、ORC格式儲存的OSS資料。
使用彈性匯入功能加速匯入時，需確保Job型資源群組中可用資源充足，避免資源不足導致任務長時間等待、耗時間長度、任務失敗等問題。
彈性匯入支援同時運行多個彈性匯入任務，也支援通過增大單個彈性匯入任務使用的資源加速匯入。更多資訊，請參見資料匯入方式介紹。
樣本如下：
/*+ elastic_load=true, elastic_load_configs=[adb.load.resource.group.name=resource_group]*/
submit job insert overwrite adb_table select * from adb_external_table;參數說明，請參見Hint參數說明。
通過DataWorks匯入資料調優
最佳化任務配置
最佳化批量插入條數
表示單次匯入的批大小，預設為2048，一般不建議修改。
如果單條資料量過大達到數百KB，如高達512 KB，則建議修改此配置為16，保證單次匯入量不超過8 MB，防止佔用過多前端節點記憶體。
最佳化通道控制
資料同步效能與任務期望最大並發數配置項大小成正比，建議儘可能增加任務期望最大並發數。
重要任務期望最大並發數越高，佔用DataWorks資源會越多，請合理選擇。
建議開啟分散式處理能力，以取得更好的同步效能。
常見問題及解決方案
當用戶端匯入壓力不足時，會導致叢集CPU使用率、磁碟IO使用率及寫入回應時間處於較低水位。資料庫伺服器端雖然能夠及時消費用戶端發送的資料，但由於總發送量較小，導致寫入TPS不滿足預期。
解決方案：調大單次匯入的批量插入條數及增加任務期望最大並發數，資料匯入效能會隨著匯入壓力的增加而線性增加。
當匯入的目標表存在資料扭曲時，叢集部分節點負載過高，影響匯入效能。此時，叢集CPU使用率、磁碟IO使用率處於較低水位，但寫入回應時間較高，同時您可以在頁面的傾斜診斷表中發現目標表。
解決方案：重新設計表結構後再匯入資料，詳情請參見表結構設計。
通過JDBC使用程式匯入資料調優
用戶端最佳化
應用端攢批，多條大量匯入
在通過JDBC使用程式匯入資料過程中，為減少網路和鏈路上的開銷，建議攢批匯入。無特殊要求，請避免單條匯入。
大量匯入條數建議為2048條。如果單條資料量過大達到數百KB，建議攢批資料大小不超過8 MB，可通過8 MB/單條資料量得到攢批條數。否則單批過大容易佔用過多前端節點記憶體，影響匯入效能。
應用端並發配置
應用端匯入資料時，建議多個並發同時匯入資料。單進程無法完全利用系統資源，且一般用戶端需要處理資料、攢批等操作，難以跟上資料庫的匯入速度，通過多並發匯入可以加快匯入速度。
匯入並發受攢批、資料來源、用戶端機器負載等影響，沒有最合適的數值，建議通過測試逐步計算合適的並發能力。如匯入不達預期，請翻倍加大並發，匯入速度下降再逐步降低並發，尋找最合適的並發數。
常見問題及解決方案
當通過程式匯入資料到AnalyticDB MySQL效能不佳時，首先排查用戶端效能是否存在瓶頸。
保證資料來源的資料生產速度足夠大，如果資料來源來自其他系統或檔案，排查用戶端是否有輸出瓶頸。
保證資料處理速度，排查資料生產消費是否同步，保證有足夠的資料等待匯入AnalyticDB MySQL。
保證用戶端機器負載，檢查CPU使用率或磁碟IO使用率等系統資源是否充足。