本文匯總了Lindorm時序引擎在資料寫入、刪除、查詢時的常見問題，方便您更加熟悉時序引擎的使用方法，規避因為不當操作可能導致的效能問題，提高使用效率。
問題導覽
資料寫入
資料查詢
資料刪除
監控
功能及效能
時序表設計
資料寫入
推薦的最優資料寫入方式是什嗎？
Java：推薦您通過Java Native SDK寫入，該方式可以自動攢批寫入和重試。詳細說明，請參見通過Java Native SDK寫入資料。
非Java：推薦使用行協議（Line Protocol）寫入。詳細說明，請參見行協議寫入。
時序引擎支援的時間精度是什嗎？
時序引擎支援毫秒（ms）層級的時間儲存，更高精度的資料會被轉換為毫秒精度進行儲存。因此，如果寫入比毫秒精度更高的時間資料，會導致原資料的精度丟失。
使用行協議寫入資料時需要注意什嗎？
使用行協議寫入時您需要注意以下三點：
Tag Key、Tag Value中的字串不需要添加半形單引號（''）或半形雙引號（""），兩者均預設為STRING類型。如果添加了半形單引號（''）或半形雙引號（""），則引號會被判定為字串的一部分。
Field Key（Field名）固定為字串類型，不需要添加半形單引號（''）或半形雙引號（""）。
Field Value（Field值）需注意資料類型：如果是字串類型，則必須添加半形雙引號（""），否則系統會報錯；如果是INT類型，則必須在數值後添加尾碼
i，例如12i、101i，否則INT類型會被識別為FLOAT類型。
想將Tag列的值設定為NULL，寫入時需要顯式寫入NULL嗎？
不需要，在寫入資料時忽略該Tag即可。假設表sensor共有5列：device_id、region、time、temperature和humidity，想讓region列值為NULL，寫入時忽略region寫入即可，例如：INSERT INTO sensor(device_id, time, temperature, humidity) VALUES ('id123', current_timestamp, 37, 70);。
資料查詢
查詢方式最推薦使用哪種？
推薦您通過JDBC Driver串連時序引擎，並使用prepareStatement綁參方式進行查詢。使用prepareStatement綁參方式可以減少服務端資源佔用，提高查詢效能。使用方式說明，請參見教程：通過JDBC Driver串連並訪問Lindorm時序引擎。
資料寫入成功但無法查詢到是什麼原因？
請檢查是否設定了資料有效期間TTL。如果寫入資料的時間超過TTL，則該資料寫入後會被清理，導致查詢結果為空白。
使用ORDER BY LIMIT可能會有什麼效能問題，有更好的查詢方式嗎？
使用ORDER BY LIMIT查詢時，資料庫需要在記憶體中對資料進行排序。如果命中的資料量過大，可能會導致服務端佔用大量記憶體進而引發穩定性問題。因此，為獲得更高的查詢效率，建議您減小查詢的時間範圍或增加更多的Tag條件，盡量減少查詢命中的資料量。
此外，時序資料預設按照時間軸返回時間遞增的資料，無需添加order by time ASC就可以得到以時間軸為基準、按時間遞增排序的資料。如果需要查詢每條時間軸的最後幾條資料，可以使用最新值函數LATEST來代替ORDER BY time DESC 。具體文法說明，請參見最新值查詢。
是否支援在WHERE條件裡對同一個Field使用多個過濾條件？
暫不支援對同一個Field列、不同的Field列使用多個過濾條件。
Field列過濾是讀取資料後再進行過濾的操作，效率較低且不支援同時對多個Field進行過濾，因此建議您使用Tag列進行過濾。
使用COUNT查詢如何獲得更高的效率？
指定一個數實值型別的Field列進行COUNT計算的效率最高。
使用Native SDK查詢時偶發報錯，內容包含關鍵詞Metaspace，應該怎麼解決？
使用Native SDK查詢時需要編譯SQL語句，佔用了過多的元空間（Metaspace），推薦您通過JDBC Driver串連時序引擎，並使用prepareStatement綁定參數的方式進行查詢。使用方式說明，請參見教程：通過JDBC Driver串連並訪問Lindorm時序引擎。
建立的連續查詢CQ未生效是什麼原因？
使用CREATE CONTINUOUS QUERY語句建立的連續查詢未生效的可能原因如下：
INSERT INTO指定的表還未建立。INSERT INTO指定的表已建立，但該表的Schema與CREATE CONTINUOUS QUERY語句指定的Schema不一致。
如果您的時序引擎為3.4.41及以上版本，建議您結合控制台查詢日誌進行排查。
查詢耗時很長是什麼原因？
請檢查查詢條件，如果未添加Tag過濾條件或者時間範圍將會掃描全表，導致查詢耗時很長。
查詢時報錯TSDBWorkPoolFullException是什麼原因？
可能是以下原因：
資料刪除
是否支援刪除一段時間範圍的資料？
暫不支援刪除指定時間範圍內的資料。當前僅支援根據指定Tag條件進行刪除，不支援根據Field和時間條件刪除。
大量的刪除操作會有什麼風險？
時序引擎在執行刪除操作時並不是直接刪除資料，而是為需要刪除的資料添加刪除標記，確保這些資料不再被查詢到，直到這些資料超過有效期間TTL被徹底清理。因此，如果提交了大量的刪除請求，則會產生大量的刪除標記，導致查詢以及後台資料的合并效能變差，更嚴重時可能會導致服務不可用。
建議您盡量避免提交大量的刪除請求，如果有資料空間清理的需求，可以通過設定TTL來實現。
是否支援刪除特定欄位？
暫不支援欄位層級的刪除操作。如果某個欄位不再使用，只要不再查詢該欄位便不會影響效能。
監控
時序熱儲存使用量會周期性下降是什麼原因？
時序引擎會根據您設定的資料保留原則周期性清理到期資料，因此該指標隔一段時間便會出現下降的情況。如果未設定，時序熱儲存使用量將持續上漲。
功能及效能
雲端硬碟擴容是否會重啟服務？
雲端硬碟擴容不會導致進程重啟，不會影響您的服務。
冷熱分界線設定後多久可以生效？
冷資料歸檔過程是在後台資料合併時進行的，當資料符合歸檔要求時將整體被歸檔至冷儲存中。但為了避免冷資料頻繁參與合并，時序引擎預設要求資料寫入7天后才會被歸檔至冷儲存，因此，如果寫入的資料已經符合歸檔要求，通常還需要等待7天該資料才會被歸檔至冷儲存，即7天后冷存策略（冷熱分界線）才會生效。
資料歸檔至冷儲存後還能再轉移回熱儲存嗎？
暫不支援將轉移至冷儲存的資料轉移回熱儲存。因此建議您合理設定冷儲存時間，經常查詢的資料不要歸檔至冷儲存。
是否支援查看錶層級的磁碟佔用情況？
暫不支援查看錶層級的儲存空間佔用情況。目前僅支援查看資料庫層級的磁碟佔用情況，如需查看請聯絡Lindorm支援人員（DingTalk號：s0s3eg3）。
時序引擎的壓縮率不太理想是什麼原因？
時序引擎對INT類型的資料壓縮率更高，如果壓縮率不夠理想，可以檢查測試資料是否為INT類型。
資料寫入時會同時寫入至記憶體和日誌，日誌資料會佔用一定的儲存空間，進而導致整體壓縮率不夠理想。
為獲得較高的壓縮率，新寫入的資料不會立刻被壓縮，需要等待在後台與已有資料合併後才會被壓縮，該過程通常需要10小時以上。
時序表設計
時序表設計時需注意什嗎？
需注意Tag的設計，避免Tag的取值範圍不可控。應盡量避免使用時間、進程號等易變資料作為表的Tag，此類資料會導致時間軸數量及時間軸索引膨脹，不利於查詢和儲存。