在使用Lindorm SQL查詢寬表資料或建立索引時,可能會遇到報錯或出現查詢效能不符合預期的情況。本文介紹Lindorm SQL使用時的常見問題和解決方案。
本文列舉的常見問題僅適用於寬表引擎。
如何解決或規避低效查詢問題?
什麼是低效查詢?低效查詢有哪些特點?
如果查詢語句中帶有過濾條件,但該過濾條件無法有效地利用已有的主鍵或索引,導致查詢時必須掃描全表,這樣的查詢被視為低效查詢。
如果執行查詢語句後,寬表引擎報錯This query may be a full table scan and thus may have unpredictable performance
,表示該查詢是低效查詢。假設test表的聯合主鍵由p1,p2,p3三個列組成,p1列是主鍵的第一列,查詢條件為SELECT * FROM test WHERE p2=10;
。此時查詢條件中未包含第一個主鍵列p1,因此該查詢語句會被認定為低效查詢語句。
由於低效查詢可能會帶來效能穩定性風險,預設情況下Lindorm會檢測並阻止低效查詢的執行。
查詢條件WHERE中的列是主鍵列或索引列,為什麼查詢還是觸發了低效查詢異常?
寬表引擎的主鍵、二級索引和MySQL聯合索引的匹配規則類似,均遵循最左匹配原則,即在多個列組成的聯合主鍵或索引中,系統從主鍵或索引鍵的第一列(最左側列)開始逐一與查詢條件中的列進行匹配。如果查詢條件中不包含主鍵或索引鍵的第一列,則此時查詢仍不會命中主鍵或二級索引,導致查詢仍然是低效查詢。
假設test表的主鍵由p1、p2、p3三個列組成,p1列是主鍵的第一列,根據最左匹配原則,查詢資料時系統將從p1列開始匹配。如果查詢條件中未包含p1列,例如SELECT * FROM test WHERE p2<30;
,此時無法匹配到主鍵第一列p1,系統不會命中主鍵進而查詢全表資料以滿足查詢條件p2<30
。
如何規避低效查詢?
以下是業務中規避低效查詢的一些推薦的方法:
使用GROUP BY查詢時報錯The diff group keys of subPlan is over lindorm.aggregate.subplan.groupby.keys.limit=..., it may cost a lot memory so we shutdown this SubPlan
?
原因:
GROUP BY
操作形成的分組數過多,可能消耗了大量的記憶體資源,從而加重執行個體負載,因此寬表引擎節流了結果集中分組數過大的查詢。
解決方案:
在查詢語句中添加過濾條件,減少最終分組數。
聯絡Lindorm支援人員(DingTalk號:s0s3eg3)調大分組數的閾值。
重要調大分組數的閾值可能會影響執行個體的穩定性。
針對多維查詢匹配情境,建議使用搜尋索引。詳細介紹,請參見搜尋索引介紹。
對開啟動態列的表執行SELECT *
查詢報錯Limit of this select statement is not set or exceeds config when select all columns from table with property DYNAMIC_COLUMNS=true
?
原因:
開啟動態列的表可能包含大量的動態列,且表的Schema定義不固定。如果對這類表進行全表掃描,將會導致IO消耗嚴重,加重執行個體負載。為避免高負載情況的產生,Lindorm寬表引擎對動態列表的查詢語句進行了限制。
解決方案:
在SELECT語句中添加LIMIT子句,限制返回結果的數量。例如SELECT * FROM test LIMIT 10;
。
為什麼建立二級索引時報錯Executing job number exceed, max job number = 8
?
原因:
一個執行個體中僅允許同時存在8個二級索引的構建任務。如果某一時刻二級索引的構建任務數已達8個,則再次建立新的二級索引時,建立語句將會報錯。
解決方案:
建議您避免同時建立大量二級索引。如果有大量建立的需求,請聯絡Lindorm支援人員(DingTalk號:s0s3eg3)。
在寬表引擎上已執行刪除列操作,為什麼重新添加同名列時會報錯column is under deleting
?
原因:
為避免由於資料類型等因素引發的髒資料問題,在您執行刪除列的操作後,寬表引擎還需要非同步清理記憶體、熱儲存和冷儲存上該列的資料。在資料全部清理完之前,系統不允許重新添加同名的新列。
解決方案:
由於資料清理由系統自行完成,可能會消耗很長時間。建議您通過以下方式加速資料的清理過程,待資料清理完成之後重新添加同名列。
假設執行了刪除列操作的表名為dt
:
-- 執行FLUSH操作,強制將記憶體中殘留的資料刷到儲存媒介上
ALTER TABLE dt FLUSH;
-- 執行COMPACTION操作,執行資料的合并和刪除
ALTER TABLE dt COMPACT;
FLUSH
文法從SQL引擎2.7.1版本開始支援。如何查看SQL引擎的版本,請參見SQL版本說明。FLUSH
操作和COMPACT
操作是非同步作業。語句執行成功並不代表資料清理完成,需要等待一段時間才能徹底清理完成。對資料量大的表執行
COMPACT
操作,其執行期間會佔用較多系統資源,因此不建議在業務高峰期執行。
建立二級索引後,寫入資料時為什麼會報錯Performing put operations with User-Defined-Timestamp in indexed column on MULTABLE_LATEST table is unsupported
?
原因:
如果寫入時顯式指定了自訂時間戳記(例如,使用UPSERT語句寫入資料時,通過/*+ _l_ts */
指定了自訂時間戳記),此時要求主表與二級索引表之間的可變性(Mutability)必須是MULTABLE_ALL
。但是出於效能考慮,Lindorm系統預設將主表與索引表的可變性配置為MULTABLE_LATEST
,在這種配置下建立二級索引並啟用會觸發可變性約束限制,導致報錯。
解決方案:
由於建立索引表後MUTABILITY參數的值不支援修改,因此您需要先刪除原有的二級索引。
刪除主表中原有的二級索引。
-- 禁用原有二級索引 ALTER INDEX IF EXISTS <原有二級索引名> ON <主表名> DISABLED; -- 刪除原有二級索引 DROP INDEX IF EXISTS <原有二級索引名> ON <主表名>;
DROP INDEX
文法的詳細介紹,請參見刪除二級索引。將主表的MUTABILITY屬性的值修改為
MUTABLE_ALL
。ALTER TABLE IF EXISTS <主表名> SET MUTABILITY='MUTABLE_ALL';
建立新的二級索引,並寫入資料。建立二級索引的文法說明,請參見CREATE INDEX。
說明自訂時間戳記的寫入方式,請參見通過HINT設定時間戳記實現多版本資料管理。
二級索引可變性約束與自訂時間戳記的關係,請參見更新自訂時間戳記的索引。