在使用Lindorm寬表引擎的過程中，如果使用方法不當，可能會出現查詢結果與預期不符的情況。本文列舉了導致此類問題產生的幾種常見原因，請您根據原因進行排查，優化查詢條件。
問題描述
Lindorm寬表引擎是兼容HBase的NoSQL數據引擎，其存儲模型是基于LSM-Tree實現的。在執行寫入操作時，數據會被先寫入預寫日志（Write-Ahead-Log，WAL）中，再寫入數據庫。只要寫入過程中沒有出現報錯，相應的數據一定會寫入成功，即使遇到機器宕機等情況，都可以通過恢復WAL的方式恢復數據，保障數據的持久性，不會出現數據寫入后非預期不可見的情況。但是由于寬表引擎的特性比較多，例如數據版本號、時間戳、TTL過期等復雜特性，如果使用不當，則可能出現寫入的數據無法覆蓋、被過期刪除等無法被查詢到或查詢不符合逾期的情況，常見原因如下：
常見原因
數據未正常寫入或查詢發起的時間在數據寫入前
在Lindorm寬表引擎中，數據寫入是即時可見的，并不會出現寫入后過一段時間才可見的情況。
Lindorm寬表經常會被應用在大數據鏈路中，如果寫入鏈路出現問題，則可能導致寫入延遲或無法正常寫入數據，此時進行數據查詢，該行數據還未寫入，因此會產生無法查詢到數據的情況。
如果您在使用中遇到數據寫入一段時間后才能查到的情況，建議您在查詢條件中添加相關HINT參數，指定查詢結果中返回數據寫入的時間戳，根據該時間戳判斷是否出現了查詢先于寫入的情況。如何返回時間戳，請參見多版本數據管理。
如果寫入數據時未指定時間戳，則返回的時間戳代表這行數據寫入的時間。
STRING字段中含有非正常的停止符或不可見字符
在查詢數據類型為STRING的字段時，如果STRING字段中包含不可見字符，則可能造成查詢結果不符合逾期的現象。假設訂單列orderID為STRING類型，由于程序bug等原因，在數據寫入時加入了不可見字符，比如訂單號1000寫成了1000(不可見字符)，即1000后跟有不可見字符，那么在使用查詢條件
where oderID="1000"時，這個包含不可見字符的字段是查詢不到的，可以使用where orderID > "1000" limit 1來確認是否存在類似問題。
此外，Lindorm不支持STRING字段的中間包含停止符（結尾有停止符是正常STRING字段）。假設寫入數據為“1000\停止符\1000”，可能會造成編碼異常，導致無法被查詢到。
查詢條件中列名填寫錯誤
可能包含以下兩種情況：
列名大小寫錯誤：Lindorm的列名是大小寫敏感的，因此在查詢時需注意查詢條件中的列名與實際寫入的列名大小寫是否一致。
未指定列簇（column family）：Lindorm寬表是支持多列簇的，如果在建表時未指定family，則寫入的列默認被添加至名為
f的family下，在數據查詢時無需在查詢條件中指定family。但如果使用了多family功能，則必須在查詢條件中指定family，否則系統將默認查詢f這個列簇下的數據，可能導致查詢結果與逾期不符。例如，創建了一個名為meta的family，并在meta下寫入了一個列column1，則在查詢column1中的數據時，必須指定family為meta，例如where meta:column1=xxx；如果未指定family，例如where column1=xxx，系統將默認查詢f列簇下的column1，導致查詢結果與實際想要得到的結果不一致。
表屬性設置了TTL，查詢時數據已過期
寬表引擎支持通過設置表屬性TTL來指定數據過期時間，TTL的單位是秒（s）。同時，寬表引擎也支持在寫入數據時指定時間戳，時間戳的單位為毫秒（ms）。
如果寫入數據時未指定時間戳，數據將在指定的TTL時長后過期。例如，指定TTL的值為一天（86400秒），那么今天寫入的數據將在明天過期被清理，無法被查詢到。
如果寫入數據時指定了較早的時間戳，并且該時間戳與當前時間的差值大于TTL設定值，那么可能在寫入時就被清理掉，導致數據寫入后無法被查詢到。
寬表引擎中的KV版本號等同于時間戳。如果您在時間戳的使用上未遵循時間語義，而是使用自定義的版本號（例如1、2、3、4這種比較小的數字），那么在表屬性設置了TTL的情況下，數據極易被過期清理。同理，使用較大的自定義時間戳/版本號，例如誤將KV的時間戳設置成微秒時間戳或者納秒時間戳，則可能造成數據無法被正常過期清理。
您可以通過集群管理系統查看TTL的值是否合適，具體步驟：在集群管理系統的概覽頁面，單擊目標數據庫下的目標表名。在當前詳情表格區域，單擊查看表屬性，查看TTL參數的值。如何進入集群管理系統，請參見登錄集群管理系統。
如果您需要修改TTL屬性的值，可以通過以下方式：
HBase Java API（Lindorm Shell）：通過Lindorm Shell訪問寬表引擎。
SQL：ALTER TABLE。
設置了Cell TTL，查詢時數據已過期
寬表引擎支持在某個鍵值對（Key-Value，KV）上設置TTL屬性，用于控制每個KV的過期時間，即Cell TLL，單位為毫秒（ms）。
如果KV上設置了Cell TTL，則其過期時間為min{Cell上設置的過期時間，表屬性上的過期時間}。過期時間的判斷是根據KV的時間戳或版本號來計算的，如果KV的時間戳過大或過小，都有可能造成數據提早被清理或一直無法被清理，導致查詢結果不符合預期。
如果同一列中存在帶有Cell TTL的KV1和沒有帶Cell TTL的KV2，在數據過期前，查詢數據時可能會讀取到時間戳已更新的KV1。在數據過期后，KV1將被清理，此時查詢數據可能會讀取到KV2，導致查詢結果不符合預期。
是否能讀到KV2，取決于設置的表屬性VERSIONS，同時還取決于到KV1和KV2是否在不同的文件中、KV1和KV2有沒有被Major Compaction操作合并。例如表的VERSIONS設置為1，文件合并發生后，由于只保留一個版本，KV2會在Major Compaction操作中被刪除，因此即使KV1被過期清理，查詢數據時也無法讀取到KV2。
刪除請求的時間戳設置不合理
Lindorm寬表引擎支持為刪除請求設置時間戳/版本號，代表刪除該行/該列在此時間/版本之前的數據，如果未設置時間戳/版本號，默認刪除當前時間/當前版本之前的數據。假設未設置時間戳，當前時間為2024年1月16日16:00:00，此時執行DELETE FROM sensor WHERE p1 = 10;表示刪除寫入時間在2024年1月16日16:00:00之前，且p1為10的一行數據。
如果刪除請求的時間戳比數據寫入的時間戳/版本號小，那么這行數據不會被刪除，此時查詢結果中依舊會包含這行數據。
如果刪除請求設置的時間戳/版本號較大，刪除請求提交后將持續生效，此時再寫入數據，則數據寫入的時間戳比刪除請求設置的時間戳小，數據寫入后會被立刻刪除，導致無法被查詢到。
SQL訪問方式不支持設置刪除時間戳。
鏈路等問題導致數據寫入后立刻被刪除
在一些大數據鏈路中，如果寫入和刪除發生在的不同的程序或進程中，則可能會出現數據寫入后被立刻刪除的情況，需要進行排查。
此外，如果您是使用阿里云實時計算Flink并采用Flink SQL方式訪問Lindorm寬表，需注意舊版本的Flink Lindorm Connector可能產生的問題：在更新Lindorm表時，如果一條Delete操作和數據寫入的時間非常接近，可能會導致寫入操作被Delete操作覆蓋。您可以通過在Flink中設置ignoreDelete=true來規避該問題。
更多介紹，請參見Flink的Lindorm Conenctor。
表屬性VERSIONS被設置為0導致數據被刪除
寬表的VERSIONS屬性的值為0，表示表中的數據不會保留，任何寫入的數據都將被刪除，無法查詢。如果建表時未設置VERSIONS屬性，則VERSIONS的值默認為1，即表中的數據僅保留一個版本。更多介紹，請參見多版本數據管理。
如果誤把VERSIONS屬性的值設置為0，建議您刪除表并重新建表，或將VERSIONS屬性修改為大于等于1的值。
您可以通過集群管理系統查看VERSIONS的值是否為0，具體步驟：在集群管理系統的概覽頁面，單擊目標數據庫下的目標表名。在當前詳情表格區域，單擊查看表屬性，查看VERSIONS參數的值。如何進入集群管理系統，請參見登錄集群管理系統。
如果您需要修改VERSIONS屬性的值，可以通過以下方式：
HBase Java API（Lindorm Shell）：通過Lindorm Shell訪問寬表引擎。
SQL：ALTER TABLE。
MIN_VERSIONS代表保留的最少版本數，該屬性默認為0，不會造成數據寫入后無法被查到的情況。
表屬性為IMMUTABLE的表有更新
表的屬性被設置成IMMUTABLE表示該表僅支持整行寫入（即一行的數據通過一條UPSERT語句寫入，不支持一行的數據通過多條UPSERT語句寫入），不可更新或刪除。但在實際操作中，即使表的屬性被設置成IMMUTABLE，Lindorm也并不會禁止更新和刪除行為，但該類操作會造成索引表和主表的數據不一致，進而導致查詢命中索引和命中主表的結果不一致。
建議您重新構建索引表，并停止更新或刪除屬性為IMMUTABLE的表中的數據。