本文介紹AnalyticDB for MySQL中寫入與查詢的常見問題及解決方案。
當常見問題情境中未明確產品系列時，表明該問題僅適用於AnalyticDB for MySQL數倉版。
常見問題概覽
企業版、基礎版及湖倉版叢集是否支援通過JDBC方式查詢Hudi表的資料？
支援。在企業版、基礎版及湖倉版叢集中建立Hudi表後，可直接通過JDBC方式查詢Hudi表的資料。
企業版、基礎版及湖倉版叢集是否支援讀取OSS中的Hudi表資料？
支援。通過外表讀取OSS中的Hudi表資料的詳細資料，請參見通過外表匯入湖倉版。
企業版、基礎版及湖倉版叢集是否支援自動切換XIHE MPP作業和XIHE BSP作業？
提交作業時，手動指定作業提交到Interactive型資源群組或Job型資源群組，決定了作業是XIHE MPP作業還是XIHE BSP作業。
企業版、基礎版及湖倉版叢集如何選擇XIHE MPP還是XIHE BSP來執行作業？
XIHE BSP預設為非同步提交作業，同步提交和非同步提交的區別在於用戶端是否需要等待查詢執行完成。
非同步提交會有如下限制：
結果集返回最多10000行。
結果集（包括對應的csv檔案下載連結）最多儲存30天，最多儲存1000個。
建議對執行時間較長、計算量較大，但結果集較小的查詢（如INSERT INTO SELECT、INSERT OVERWRITE SELECT、CREATE TABLE AS SELECT等）使用非同步提交。
企業版、基礎版及湖倉版叢集如何查看XIHE BSP作業的狀態？
如果湖倉版叢集是通過作業編輯器提交的XIHE BSP作業，可在作業編輯器SQL開發頁面下方的執行歷史頁簽查看。
如果湖倉版叢集不是通過作業編輯器提交的XIHE BSP作業，可通過系統內部提供的記憶體表查看。方法如下：
SELECT status FROM information_schema.kepler_meta_elastic_job_list WHERE process_id='<job_id>';查詢XIHE BSP作業的狀態統計，方法如下。
SELECT status,count(*) FROM information_schema.kepler_meta_elastic_job_list GROUP BY status;
如何進行資源隔離，減少SQL任務間的相互影響？
數倉版彈性模式叢集和企業版、基礎版及湖倉版叢集支援資源群組功能，資源群組類型的詳細資料請參見數倉版資源群組介紹和湖倉版資源群組介紹。您可以通過建立不同類型的資源群組，將SQL作業提交到對應的資源群組執行達到資源隔離的效果。
如何處理IN條件過多的問題？
AnalyticDB for MySQL對於IN條件的個數有限制，IN條件個數預設為2000，您也可以根據需求進行調整。
IN條件的個數最大不能超過5000，超過5000會影響效能。
例如將IN條件的個數限制設定為3000，語句如下：
SET ADB_CONFIG max_in_items_count=3000;如何解決查詢資料時提示“Query exceeded maximum time limit of 1800000.00ms”？
AnalyticDB for MySQL對SQL查詢執行設定有逾時時間，該SQL執行時間超過了預設時間1800000.00ms。您可以為單個查詢或全叢集所有查詢配置查詢的逾時時間，樣本如下：
單個查詢生效。
/*+ QUERY_TIMEOUT=xxx */SELECT count(*) FROM t;全叢集所有查詢生效。
SET ADB_CONFIG QUERY_TIMEOUT=xxx;更多資訊，請參見常見配置參數。
如何解決查詢資料時提示“Out of Memory Pool size pre cal. available 0 require 3”？
原因：AnalyticDB for MySQL叢集中可能存在執行中的大SQL，這些SQL消耗了大量的記憶體，從而導致執行本次提交的SQL查詢時記憶體不足。
建議：您可以稍等幾分鐘後，重新執行SQL。
如何解決查詢資料時提示“STORAGE_INDEX_ERROR, msg:Index does not exist”？
原因：該錯誤是由AnalyticDB for MySQL某些存量核心版本中的一個已知缺陷所引發。在特定條件下，此缺陷可能導致表的索引中繼資料出現不一致，從而在查詢時無法找到索引，觸發 STORAGE_INDEX_ERROR 異常。
建議：升級叢集的核心版本，新版本核心已修複此缺陷。
升級耗時：核心版本升級過程通常需要約 30分鐘。
服務中斷：在升級過程中，叢集會發生一次秒級的串連閃斷。
操作建議：強烈建議您在計劃好的維護視窗或業務低峰期執行升級操作，並確保您的應用程式具備自動重連機制，以平滑應對此次串連閃斷。
如何解決使用Multi-Statement功能連續執行多個SQL語句時提示“multi-statement be found”？
僅3.1.9.3及以上核心版本的叢集支援Multi-Statement功能，您需先查看叢集核心版本是否符合要求，若核心版本低於3.1.9.3，請聯絡支援人員升級版本；若核心版本高於3.1.9.3，但仍有該報錯，可能是因為用戶端未開啟Multi-Statement功能。
例如，使用MySQL JDBC用戶端串連叢集時，不僅需要執行SET ADB_CONFIG ALLOW_MULTI_QUERIES=true;命令手動開啟Multi-Statement功能，還需將JDBC串連屬性allowMultiQueries配置為true。
如何排查返回結果中的時間被截斷的問題？
先通過MySQL用戶端進行驗證，如果MySQL用戶端顯示正常，那麼需要定位您使用的其他用戶端軟體對返回結果是否做過特殊處理。
如何解決AES_ENCRYPT內建函數報錯？
執行以下語句，出現報錯。
SELECT CONVERT(AES_DECRYPT(AES_ENCRYPT('ABC123','key_string'),'key_string'),char(10));原因為AES_ENCRYPT(NCRYPT(varbinary x, varchar y)語句中x的資料類型需為varbinary。SQL樣本如下。
SELECT CONVERT(AES_DECRYPT(AES_ENCRYPT(CAST('ABC123' AS VARBINARY), 'key_string'), 'key_string'),char(10)); 為什麼會發生查詢結果跳變？
在確認資料沒有更新的情況下，可能導致查詢結果跳變的原因如下：
沒有排序的LIMIT。AnalyticDB for MySQL是分散式資料庫，查詢在多個節點多線程執行，如果某些線程返回了滿足LIMIT的行數，查詢即終止，所以沒有排序的LIMIT的查詢結果是一個隨機的過程，內部無法保證固定的線程返回結果。
帶分組的彙總查詢，如果SELECT欄位中的某個欄位沒有彙總函式，也沒有出現在GROUP BY欄位中，那麼這個欄位將隨機返回一個值。
若仍有問題，請聯絡支援人員。
為什麼單表的排序（ORDER BY）查詢耗時間長度？
原因：資料在儲存層沒有排序，儲存的比較分散，會產生大量的無效資料讀取，因此查詢耗時會變長。
建議：您可以為進行ORDER BY的欄位增加叢集索引（CLUSTERED KEY）。增加叢集索引後，資料會在儲存層先完成初步排序，在進行ORDER BY查詢時，僅需讀取少量資料，進而提升查詢效能。增加叢集索引的方法，請參見增加叢集索引。
一張表僅支援建立一個叢集索引，若其他欄位已經有叢集索引，需先刪除，再為ORDER BY的欄位增加叢集索引。
大表在增加叢集索引之後，會增加BUILD任務的耗時，進而影響儲存節點的CPU使用率。
為什麼執行計畫裡的表掃描行數累加不等於查詢的總掃描行數？
一般是由於建立了複製表導致的，複製表在AnalyticDB for MySQL的每個Shard都儲存一份資料，當查詢複製表時，複製表的查詢會在掃描量統計時重複統計。
為什麼沒有設定主鍵（primary key）的表，用INSERT OVERWRITE插入，會出現重複資料？
AnalyticDB for MySQL中沒有設定主鍵的表不支援自動去重。
為什麼使用查詢語句SELECT * FROM TABLE GROUP BY KEY後，報錯“Column 'XXX' not in GROUP BY clause”？
分組查詢時不支援使用查詢語句SELECT * FROM table GROUP BY key展示查詢所有欄位，需要顯式列出所有欄位。SQL樣本如下。
SELECT nation.name FROM nation GROUP BY nation.nationkey為什麼執行INSERT OVERWRITE SELECT語句後，原表的資料沒有被覆蓋？
原因：在執行INSERT OVERWRITE語句時，是對相同分區的資料進行覆蓋，新分區將覆蓋舊分區。當SELECT結果為空白時，意味著沒有新的分區，因此也不會對原表中已有的資料進行覆蓋。
解決方案：修改INSERT OVERWRITE SELECT語句，確保SELECT結果不為空白，才能覆蓋原表的資料。
查詢結果以JSON格式返回時，IN操作符指定值的個數有限制嗎？
AnalyticDB for MySQL核心版本為3.1.4及以下版本的叢集對IN操作符指定值的個數有限制且個數不能超過16，核心版本為3.1.4以上版本的叢集沒有限制。查看叢集的核心版本的操作步驟，請參見如何查看叢集的核心版本？。
是否支援OSS上經過GZIP壓縮後的CSV檔案做為外表資料來源？
AnalyticDB for MySQL支援OSS上經過GZIP壓縮後的CSV檔案做為外表資料來源，需要compress_type外表定義加上compress_type=gzip。OSS外表文法，請參見OSS非分區外表。
是否支援INSERT ON DUPLICATE KEY？
AnalyticDB for MySQL目前只支援等值更新，不支援算數運算式。
是否支援在UPDATE語句中使用Join？
僅核心版本為3.1.6.4及以上版本的AnalyticDB for MySQL叢集支援。詳情請參見UPDATE。
是否支援在SQL裡設定變數？
AnalyticDB for MySQL不支援在SQL裡設定變數。
是否支援通過Logstash外掛程式使用INSERT ON DUPLICATE KEY UPDATE語句批量插入資料？
支援。使用INSERT ON DUPLICATE KEY UPDATE語句批量插入資料時，您無需在每個VALUES()語句後都添加ON DUPLICATE KEY UPDATE，僅需在最後一個VALUES()後加上即可。
例如，需要在student_course表中批量插入3條資料時，執行如下語句：
INSERT INTO student_course(`id`, `user_id`, `nc_id`, `nc_user_id`, `nc_commodity_id`, `course_no`, `course_name`, `business_id`)
VALUES(277943, 11056941, '1001EE1000000043G2T5', '1001EE1000000043G2TO', '1001A5100000003YABO2', 'kckm303', '工業會計實戰V9.0--77', 'kuaiji'),
(277944, 11056943, '1001EE1000000043G2T5', '1001EE1000000043G2TO', '1001A5100000003YABO2', 'kckm303', '工業會計實戰V9.0--88', 'kuaiji'),
(277945, 11056944, '1001EE1000000043G2T5', '1001EE1000000043G2TO', '1001A5100000003YABO2', 'kckm303', '工業會計實戰V9.0--99', 'kuaiji')
ON DUPLICATE KEY UPDATE
course_name = '工業會計實戰V9.0--77',
business_id = 'kuaiji';載入內建資料集需要滿足什麼條件？
叢集具有至少24 ACU的儲存預留資源，且user_default資源群組中至少有16 ACU的計算預留資源。
如何判斷內建資料集是否載入成功？
在作業開發SQL開發頁面可查看載入進度。當加載內置數據集前出現
並為灰質狀態，且庫表頁簽下可以查看到ADB_SampleData_TPCH資料庫及相關的表，則為載入成功。
載入內建資料集時，提示載入失敗或者長時間載入中如何處理？
您需要先通過SQL語句DROP TABLE table_name;刪除庫中的所有表。表刪除以後，再通過SQL語句DROP DATABASE ADB_SampleData_TPCH;刪除內建資料集的庫。刪除ADB_SampleData_TPCH資料庫後，重新載入資料集。
資料庫普通帳號如何使用內建資料集？
內建資料集功能遵循AnalyticDB for MySQL的許可權管理規則，即使叢集已載入內建資料集，資料庫普通帳號沒有ADB_SampleData_TPCH資料庫的許可權也無法使用，需要高許可權帳號為普通帳號授權。授權語句為：
GRANT select ON ADB_SampleData_TPCH.* TO <user_name>;內建資料集載入完成後，如何進行測試？
資料集載入成功後，AnalyticDB for MySQL預設提供對應的查詢指令碼，您可以在SQL開發頁面的指令碼頁簽執行樣本查詢語句。查詢語句的詳情，請參見TPC-H測試集。
為保證資料集的完整性，建議僅對ADB_SampleData_TPCH資料庫執行查詢操作。若由於DDL或DML變更導致資料集載入狀態異常，請嘗試刪除ADB_SampleData_TPCH資料庫並重試載入資料集。