在使用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技術支持（釘釘號：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技術支持（釘釘號：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設置時間戳實現多版本數據管理。
二級索引可變性約束與自定義時間戳的關系，請參見更新自定義時間戳的索引。