全部產品
Search
文件中心

Lindorm:常見問題

更新時間:Aug 15, 2024

在使用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

如何規避低效查詢?

以下是業務中規避低效查詢的一些推薦的方法:

  • 最佳化查詢條件,在WHERE語句中增加表的主鍵,或保證查詢條件中的列滿足最左匹配原則。

  • 修改表的主鍵設計,避免大查詢。詳細介紹,請參見如何設計寬表主鍵

  • 為表建立二級索引。詳細介紹,請參見二級索引

  • 如果表的多個列均存在多維檢索需求,可以給表建立多維搜尋索引加速查詢。詳細介紹,請參見搜尋索引

  • 在查詢語句中增加查詢最佳化的HINT:/*+ _l_allow_filtering_ */,強制寬表引擎執行低效查詢。例如SELECT /*+ _l_allow_filtering_ */ * FROM dt WHERE nonPK=100;

    重要

    強制執行低效查詢可能會帶來效能穩定性風險,請謹慎使用。

使用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參數的值不支援修改,因此您需要先刪除原有的二級索引。

  1. 刪除主表中原有的二級索引。

    -- 禁用原有二級索引
    ALTER INDEX IF EXISTS <原有二級索引名> ON <主表名> DISABLED;
    
    -- 刪除原有二級索引
    DROP INDEX IF EXISTS <原有二級索引名> ON <主表名>;

    DROP INDEX文法的詳細介紹,請參見刪除二級索引

  2. 將主表的MUTABILITY屬性的值修改為MUTABLE_ALL

    ALTER TABLE IF EXISTS <主表名> SET MUTABILITY='MUTABLE_ALL';
  3. 建立新的二級索引,並寫入資料。建立二級索引的文法說明,請參見CREATE INDEX

    說明