FAQ - Time Series Database

本頁面討論了經常容易混淆的內容，以及跟其它資料庫系統相比TSDB For InfluxDB®以意想不到的方式啟動並執行地方。

問題導覽

序列和序列基數

為什麼序列基數很重要？

TSDB For InfluxDB®維護系統中每個序列在記憶體中的索引。隨著序列數量不斷增加，RAM（記憶體）使用量也在不斷增加。序列基數過大會導致作業系統終止TSDB For InfluxDB®進程，並拋出記憶體不足（OOM）異常。InfluxQL參考

如何進行建模，有什麼注意事項？

不建議儲存大量時間軸，建議時間軸量級保持在100w以下，海量時間軸情境建議使用Lindorm 時序引擎簡介。其次，開始建模前請先參考InfluxDB 建模指南。雖然InfluxDB會對tag建立索引來加速查詢，但是過多的tag會因時間軸膨脹而導致查詢/寫入速度降低，因此在建模上需要注意控制時間軸的數量，特別是以下幾點：

避免使用id、hash值和時間等極易無限膨脹的值作為tag。
避免在measurement和tag的命名中儲存資料資訊，請將相關資訊儲存到tag或field中。
避免在一個tag中儲存多個資訊，可以拆解成多個tag。
需要經常使用Group by欄位，可以當作tag來建模。

管理（Administration）

關於系統穩定性需要注意什嗎？

記憶體水位需保持在80%以下。
控制時間軸數量，保持時間軸量級在100萬以下，建議您參考建模注意事項合理規劃。
控制measurement數量，建議您參考建模注意事項合理規劃。
控制合適的資料總量，建議設定資料保留原則，定期刪除舊資料。
控制Shard數量和並發寫入的Shard數量，建議合理設定Shard Group時間長度，不宜過長或過短，同時通過設定資料保留原則時間長度刪除舊的Shard。

如何查看measurement的磁碟使用量？

無法查看measurement層級的磁碟佔用情況。measurement是邏輯概念，同一Database下所有的measurement在底層資料檔案中是混存的。

如何高效安全地刪除資料？

InfluxDB的drop measurement 、drop series、delete採用邏輯刪除，該刪除方式有以下幾點缺陷：

InfluxDB 1.X在代碼實現層面存在死結的可能性。
查詢需要過濾被刪除的時間軸，嚴重影響查詢效率。
邏輯刪除無法立刻釋放磁碟空間，需要等待後台資料合併調度，空間釋放慢。

建議通過修改資料保留原則來刪除老資料，或使用drop shard或drop database進行物理刪除。

為什麼修改保留原則後不生效？

在v1.8.13及以後版本，修改保留原則後立即生效，若沒有生效請檢查以下兩點：

版本是否為v1.8.12或更老的版本，老版本中修改保留原則需要等待後台調度，請耐心等待30~60分鐘。
Shard覆蓋的時間範圍較大，可以通過show shards查看，只有目前時間超過Shard的結束時間時，該Shard才可以被刪除。

為什麼服務經常中斷？

檢查記憶體水位是否比較高，一般記憶體水位超過80%以上，可能會出現記憶體上漲導致的進程OOM，建議您參考FAQ：記憶體佔用為什麼很高，排查記憶體佔用較高的根本原因或對執行個體進行升配。

記憶體佔用為什麼很高？是否需要升配？

記憶體佔用高主要有以下幾點原因：

時間軸數量多。索引合并時會佔用大量記憶體，請排查schema設計是否合理，不建議儲存超過100W的時間軸。海量時間軸情境詳情，請參見Lindorm 時序引擎簡介。
資料量大或Shard數量多。資料量越大，空間佔用越多，資料檔案合并也會佔用大量記憶體，而且重啟花費的時間也會比較長，建議您參考FAQ：如何高效安全地刪除資料，將部分資料安全刪除。大量資料存放區情境詳情，請參見Lindorm 時序引擎簡介。
存在大查詢。避免使用大查詢，建議查詢時候帶上 tag 和時間過濾，減少資料掃描的範圍。
如果有使用Grafana查詢，Grafana在配置圖表時可能會下發show tag keys的查詢，此類查詢會瞬間佔用過多的記憶體導致進程OOM。推薦升級到v1.8.13後，可以配置禁用show tag keys的查詢。

若無法避免上述問題，當記憶體水位超過80%以上時，建議您對執行個體進行升配。升配操作詳情，請參見升配或降配。

儲存是否支援縮容？

InfluxDB底層儲存使用的是雲端硬碟，目前雲端硬碟不支援縮容。

雲端硬碟擴容是否會重啟？

InfluxDB雲端硬碟擴容時進程會重啟。如果是單機版本，重啟期間可能會導致服務的不可用。如果是高可用版本，三節點會滾動重啟，業務一般不會受到影響。

重啟需要多長時間？

InfluxDB 重啟時間和儲存的資料量有關，一般儲存的資料量越大，重啟所需的時間越長。

是否支援InfluxDB內建的Grafana？

建議使用阿里雲產品可觀測可視化 Grafana 版。不建議使用InfluxDB內建的Grafana，因為InfluxDB內建的Grafana版本比較舊而且不再維護更新。

為什麼訪問出現`ip block`錯誤？

v1.8.12及以下版本會在錯誤密碼重試太多時臨時禁用IP，建議升級到v1.8.13及以上版本。

如何識別TSDB For InfluxDB®的版本？

有多種方法可以識別您正在使用的TSDB For InfluxDB®版本：

curl路徑/ping

$ curl -i 'https://<網路地址>:3242/ping?u=<帳號名稱>&p=<密碼>'
HTTP/1.1204NoContent
Content-Type: application/json
X-Influxdb-Build: OSS
X-Influxdb-Version:1.7.x

啟動TSDB For InfluxDB®的命令列介面

$ influx -ssl -username <帳號名稱>-password <密碼>-host <網路地址>-port 3242

Connected to https://<網路地址>:3242 version 1.7.x

Shard Group Duration和保留原則之間的關係是什嗎？

TSDB For InfluxDB®將資料存放區在Shard Group。一個Shard Group覆蓋一個特定的時間間隔；TSDB For InfluxDB®通過查看相關保留原則（Retention Policy）的DURATION來確定時間間隔。下表列出了RP的DURATION和一個Shard Group的時間間隔之間的預設關係：

RP期間（duration）	Shard Group時間間隔
< 2 days	1 hour
>= 2 days and <= 6 months	1 day
> 6 months	7 days

使用SHOW RETENTION POLICIES查看保留原則的Shard Group Duration。

當更改保留原則後，為什麼資料沒有丟失？

有可能是以下原因，導致保留原則改變後資料沒有馬上丟失：

第一個可能的原因（最有可能的情境）：預設情況下，TSDB For InfluxDB®每30分鐘檢查並強制執行一次RP。您可能需要等到下一次RP檢查，TSDB For InfluxDB®才能刪除在RP的新DURATION之外的資料。
第二個可能的原因：更改RP的DURATION和SHARD DURATION會導致意外的資料保留。TSDB For InfluxDB®將資料存放區在Shard Group，每個Shard Group覆蓋一個特定的RP和時間間隔。當TSDB For InfluxDB®強制執行RP時，整個Shard Group的資料會被刪除，而不是單個資料點。TSDB For InfluxDB®不能拆分Shard Group。如果RP的新DURATION小於舊的SHARD DURATION，並且TSDB For InfluxDB®正在將資料寫入一箇舊的、DURATION較長的Shard Group，那麼系統將強制把所有資料存放區在該Shard Group中，即使該Shard Group中有些資料已經在新的DURATION之外。一旦Shard Group中所有資料都在新的DURATION之外，TSDB For InfluxDB®將會刪除整個Shard Group，然後系統開始將資料寫入具有新的、更短SHARD DURATION的Shard Group，避免進一步意想不到的資料保留。

為什麼TSDB For InfluxDB®無法解析微秒單位？

在不同情境下寫入、查詢以及在TSDB For InfluxDB®命令列介面（Influx CLI）設定精度，用於指定微秒時間單位的文法也不同。下表顯示了每個類別支援的文法：

	使用HTTP API寫入資料	所有查詢	在Influx CLI設定精度
u	√	√	√
us	❌	❌	❌
µ	❌	√	❌
µs	❌	❌	❌

資料查詢

如何排查慢查詢的原因？

慢查詢一般是由於掃描了過多時間軸或未經處理資料導致，因此，建議為每個查詢都加上tag過濾條件和時間範圍過濾條件。此外可以使用EXPLAIN ANALYZE命令查看自查與最佳化查詢，execution_time主要包括未經處理資料讀取時間和計算時間，planning_time主要包括時間軸掃描時間，可以針對這兩個時間最佳化查詢過濾條件。

什麼決定了`GROUP BY time()`查詢返回的時間間隔？

GROUP BY time()查詢返回的時間間隔符合TSDB For InfluxDB®的預設時間段或者符合使用者指定的位移間隔。樣本如下：

預設時間段
以下查詢計算sunflowers在6:15pm到7:45pm之間的平均值，並將這些平均值按一小時進行分組：
```
SELECT mean("sunflowers")
FROM "flower_orders"
WHERE time >='2016-08-29T18:15:00Z' AND time <='2016-08-29T19:45:00Z' GROUP BY time(1h)
```
下面的結果展示了TSDB For InfluxDB®如何維護它的預設時間段。
在這個樣本中，6pm是一個預設的時間段，7pm也是一個預設的時間段。由於WHERE子句中指定了查詢的時間範圍，所以在計算6pm時間段對應的平均值時不包括在6:15pm之前的資料，但是用於計算6pm時間段平均值的資料必鬚髮生在6pm這個小時裡。對於7pm時間段也是一樣；用於計算7pm時間段平均值的資料必鬚髮生在7pm這個小時裡。虛線部分展示了用於計算每個平均值的資料點。
請注意，雖然結果中第一個時間戳記是2016-08-29T18:00:00Z，但是在該時間段的查詢結果不包含發生在2016-08-29T18:15:00Z（WHERE子句中指定的開始時間）之前的資料。
未經處理資料結果：
```
name: flower_orders                                name: flower_orders
—————————-------------------
time                    sunflowers                 time                  mean
2016-08-29T18:00:00Z342016-08-29T18:00:00Z22.332
|--|2016-08-29T19:00:00Z62.75
2016-08-29T18:15:00Z|28|
2016-08-29T18:30:00Z|19|
2016-08-29T18:45:00Z|20|
|--|
|--|
2016-08-29T19:00:00Z|56|
2016-08-29T19:15:00Z|76|
2016-08-29T19:30:00Z|29|
2016-08-29T19:45:00Z|90|
|--|
2016-08-29T20:00:00Z70
```

位移間隔

以下查詢計算sunflowers在6:15pm到7:45pm之間的平均值，並將這些平均值按一小時進行分組，同時，該查詢還將TSDB For InfluxDB®的預設時間段位移15分鐘：

SELECT mean("sunflowers")
FROM "flower_orders"
WHERE time >='2016-08-29T18:15:00Z' AND time <='2016-08-29T19:45:00Z' GROUP BY time(1h,15m)
---
|
                                                                                  offset interval

在這個樣本中，使用者指定的位移間隔將TSDB For InfluxDB®的預設時間段前移了15分鐘。現在，6pm時間段的平均值包括在6:15pm和7:15pm之間的資料，7pm時間段的平均值包括在7:15pm和8:15pm之間的資料。虛線部分展示了用於計算每個平均值的資料點。

請注意，現在結果中第一個時間戳記是2016-08-29T18:15:00Z，而不是2016-08-29T18:00:00Z。

未經處理資料結果：

name: flower_orders                                name: flower_orders
—————————-------------------
time                    sunflowers                 time                  mean
2016-08-29T18:00:00Z342016-08-29T18:15:00Z30.75
|--|2016-08-29T19:15:00Z65
2016-08-29T18:15:00Z|28|
2016-08-29T18:30:00Z|19|
2016-08-29T18:45:00Z|20|
2016-08-29T19:00:00Z|56|
|--|
|--|
2016-08-29T19:15:00Z|76|
2016-08-29T19:30:00Z|29|
2016-08-29T19:45:00Z|90|
2016-08-29T20:00:00Z|70|
|--|

為什麼查詢沒有返回任何資料或者只返回一部分資料？

對於為什麼查詢沒有返回任何資料或者只返回一部分資料，有幾種可能的解釋。我們在下面列出了一些最常見的原因：

保留原則
第一個也是最常見的解釋與保留原則（RP）有關。TSDB For InfluxDB®自動從資料庫的預設（DEFAULT）RP中查詢資料。如果您的資料不是儲存在預設的RP，TSDB For InfluxDB®不會返回任何結果，除非您明確指定所使用的RP。
SELECT子句中的tag key
在SELECT子句中，至少需要包含一個field key，查詢才會返回資料。如果SELECT子句只包含一個或多個tag key，查詢會返回空的結果。請查看文檔資料探索獲得更多相關資訊。
查詢時間範圍
另一個可能的解釋與查詢的時間範圍有關。預設情況下，大多數SELECT查詢涵蓋在1677-09-21 00:12:43.145224194 UTC和2262-04-11T23:47:16.854775806Z UTC之間的時間範圍。SELECT查詢還包括GROUP BY time()子句，但是，它涵蓋的時間範圍在1677-09-21 00:12:43.145224194和now()之間。如果您的資料發生在now()之後，那麼GROUP BY time()查詢不會覆蓋這些發生在now()之後的資料。如果查詢語句包括GROUP BY time()子句，並且有資料發生在now()之後，您需要為時間範圍提供一個上限。
標識符名字
最後一個常見的解釋與Schema有關（field和tag有相同的名字）。如果field key和tag key相同，那麼在所有查詢中優先考慮field。在查詢中，你需要使用::tag文法指定tag key。

為什麼`GROUP BY time()`查詢不返回傳生在`now()`之後的時間戳記？

大多數SELECT語句的預設時間範圍在1677-09-21 00:12:43.145224194 UTC和2262-04-11T23:47:16.854775806Z UTC之間。對於帶GROUP BY time()子句的SELECT語句，預設的時間範圍在1677-09-21 00:12:43.145224194和now()之間。

如果要查詢時間戳記發生在now()之後的資料，帶GROUP BY time()子句的SELECT語句必須在WHERE子句中提供一個時間上限。

在下面的樣本中，第一個查詢涵蓋時間戳記在2015-09-18T21:30:00Z和now()之間的資料，第二個查詢涵蓋時間戳記在2015-09-18T21:30:00Z和now()之後180個星期之間的資料。

> SELECT MEAN("boards") FROM "hillvalley" WHERE time >='2015-09-18T21:30:00Z' GROUP BY time(12m) fill(none)


> SELECT MEAN("boards") FROM "hillvalley" WHERE time >='2015-09-18T21:30:00Z' AND time <= now()+180w GROUP BY time(12m) fill(none)

請注意，WHERE子句必須提供一個時間上線來覆蓋預設的now()上限。下面的查詢只是將now()的下限重設，使得查詢的時間範圍在now()和now()之間：

> SELECT MEAN("boards") FROM "hillvalley" WHERE time >= now() GROUP BY time(12m) fill(none)
>

請查看資料探索獲得更多關於時間文法的資訊。

是否可以對時間戳記執行數學運算？

目前，在TSDB For InfluxDB®中，不能對時間戳記執行數學運算。更多關於時間的計算必須由接收查詢結果的用戶端執行。

對時間戳記使用InfluxQL函數，TSDB For InfluxDB®僅提供有限的支援。ELAPSED()函數返回單個field中時間戳記之間的差值。

是否可以從返回的時間戳記中識別寫入精度？

不管提供的寫入精度是多少，TSDB For InfluxDB®將所有時間戳記儲存為納秒。需要注意的一個重要事項是，當返回查詢結果時，資料庫會不動聲色地刪除時間戳記後面的零，使原始的寫入精度很難識別。

在下面的樣本中，tag precision_supplied和timestamp_supplied分別顯示了使用者在寫入資料時提供的時間精度和時間戳記。因為TSDB For InfluxDB®默默地將返回的時間戳記後面的零刪除了，所以從返回的時間戳記中很難識別寫入精度。

name: trails
-------------
time                  value  precision_supplied  timestamp_supplied
1970-01-01T01:00:00Z3      n                   3600000000000
1970-01-01T01:00:00Z5      h                   1
1970-01-01T02:00:00Z4      n                   7200000000000
1970-01-01T02:00:00Z6      h                   2

當查詢資料時，什麼時候應該使用單引號，什麼時候應該使用雙引號？

用單引號將字串類型的值括起來（例如：tag value），但是不要用單引號將標識符（資料庫名字、保留原則名字、使用者名稱、measurement的名字、tag key和field key）括起來。

如果標識符以數字開頭，或包含除[A-z,0-9,_]外的字元，或者標識符是InfluxQL關鍵字，那麼需要使用雙引號將標識符括起來。如果標識符不屬於這些類別之一，可以不需要使用雙引號將它們括起來，但是我們還是建議用雙引號將它們括起來。

樣本：

合法的查詢：SELECT bikes_available FROM bikes WHERE station_id='9'

合法的查詢：SELECT "bikes_available" FROM "bikes" WHERE "station_id"='9'

合法的查詢：SELECT MIN("avgrq-sz") AS "min_avgrq-sz" FROM telegraf

合法的查詢：SELECT * from "cr@zy" where "p^e"='2'

非法的查詢：SELECT 'bikes_available' FROM 'bikes' WHERE 'station_id'="9"

非法的查詢：SELECT * from cr@zy where p^e='2'

用單引號將日期時間字串括起來。如果您使用雙引號將日期時間字串括起來，TSDB For InfluxDB®會返回錯誤（ERR: invalid operation: time and *influxql.VarRef are not compatible）。

樣本：

合法的查詢：SELECT "water_level" FROM "h2o_feet" WHERE time > '2015-08-18T23:00:01.232000000Z' AND time < '2015-09-19'

非法的查詢：SELECT "water_level" FROM "h2o_feet" WHERE time > "2015-08-18T23:00:01.232000000Z" AND time < "2015-09-19"

請查看資料探索獲得更多關於時間文法的資訊。

為什麼在建立一個新的預設（`DEFAULT`）保留原則後會遺失資料？

當您在資料庫中建立一個新的預設保留原則（RP）後，在舊的預設RP中的資料依舊儲存在舊的RP中。對於不指定RP的查詢，將會自動查詢新預設RP中的資料，所有舊資料可能會丟失。為了查詢舊資料，必須完全限定查詢中的資料。樣本如下：

在measurement fleeting中的所有資料屬於預設的RP，該RP的名字為one_hour：

> SELECT count(flounders) FROM fleeting
name: fleeting
--------------
time                     count
1970-01-01T00:00:00Z8

現在我們建立一個新的預設RP（two_hour），並執行相同的查詢：

> SELECT count(flounders) FROM fleeting
>

為了查詢舊資料，我們必須通過完全限定fleeting來指定舊的預設RP：

> SELECT count(flounders) FROM fish.one_hour.fleeting
name: fleeting
--------------
time                     count
1970-01-01T00:00:00Z8

為什麼帶有`WHERE OR`時間子句的查詢返回空結果？

目前，TSDB For InfluxDB®不支援在WHERE子句中使用OR來指定多個時間範圍。如果查詢中的WHERE子句使用OR來指定多個時間範圍，那麼TSDB For InfluxDB®不會返回任何結果。

樣本：

> SELECT * FROM "absolutismus" WHERE time ='2016-07-31T20:07:00Z' OR time ='2016-07-31T23:07:17Z'
>

為什麼`fill(previous)`返回空結果？

如果前一個值在查詢的時間範圍之外，那麼fill(previous)不會填充該時間段的值。

在下面的樣本中，TSDB For InfluxDB®不會使用時間段2016-07-12T16:50:00Z-2016-07-12T16:50:10Z的值填充時間段2016-07-12T16:50:20Z-2016-07-12T16:50:30Z，因為該查詢的時間範圍並不包含較早的時間段。

樣本資料：

> SELECT * FROM "cupcakes"
name: cupcakes
--------------
time                   chocolate
2016-07-12T16:50:00Z3
2016-07-12T16:50:10Z2
2016-07-12T16:50:40Z12
2016-07-12T16:50:50Z11

GROUP BY time()查詢：

> SELECT max("chocolate") FROM "cupcakes" WHERE time >='2016-07-12T16:50:20Z' AND time <='2016-07-12T16:51:10Z' GROUP BY time(20s) fill(previous)
name: cupcakes
--------------
time                   max
2016-07-12T16:50:20Z
2016-07-12T16:50:40Z12
2016-07-12T16:51:00Z12

為什麼`INTO`查詢會遺失資料？

預設情況下，INTO查詢將未經處理資料中的tag轉換成新寫入資料的field。這會導致TSDB For InfluxDB®覆蓋之前由tag區分的資料點。在所有INTO查詢中加上GROUP BY *，可以將tag保留在新寫入的資料中。

說明

這種方式不適用於使用TOP()或BOTTOM()函數的查詢。請查看文檔InfluxDB函數獲得更多關於TOP()和BOTTOM()的資訊。

樣本資料

measurement french_bulldogs包含一個tag color和一個field name。

> SELECT * FROM "french_bulldogs"
name: french_bulldogs
---------------------
time                  color  name
2016-05-25T00:05:00Z  peach  nugget
2016-05-25T00:05:00Z  grey   rumple
2016-05-25T00:10:00Z  black  prince

不使用GROUP BY *的INTO查詢
不使用GROUP BY *子句的INTO查詢將tag color轉換成新寫入資料中的field。在未經處理資料中，資料點nugget和rumple僅由tag color區分。一旦color變成field，TSDB For InfluxDB®會認為資料點nugget和rumple是重複的，它會用資料點rumple將資料點nugget覆蓋。
```
> SELECT * INTO "all_dogs" FROM "french_bulldogs"
name: result
------------
time                  written
1970-01-01T00:00:00Z3

> SELECT * FROM "all_dogs"
name: all_dogs
--------------
time                  color  name
2016-05-25T00:05:00Z  grey   rumple                <---- no more nugget
2016-05-25T00:10:00Z  black  prince
```

使用GROUP BY *的INTO查詢

使用GROUP BY *子句的INTO查詢將tag color保留在新寫入的資料中。在這種情況下，資料點nugget和rumple依舊是不同的資料點，TSDB For InfluxDB®不會覆蓋任何資料。

> SELECT "name" INTO "all_dogs" FROM "french_bulldogs" GROUP BY *
name: result
------------
time                  written
1970-01-01T00:00:00Z3

> SELECT * FROM "all_dogs"
name: all_dogs
--------------
time                  color  name
2016-05-25T00:05:00Z  peach  nugget
2016-05-25T00:05:00Z  grey   rumple
2016-05-25T00:10:00Z  black  prince

如何查詢tag key和field key名字相同的資料？

使用文法::指定一個key是field key還是tag key。樣本資料：

> INSERT candied,almonds=true almonds=50,half_almonds=511465317610000000000
> INSERT candied,almonds=true almonds=55,half_almonds=561465317620000000000

> SELECT * FROM "candied"
name: candied
-------------
time                   almonds  almonds_1  half_almonds
2016-06-07T16:40:10Z50       true       51
2016-06-07T16:40:20Z55       true       56

指定key是field

> SELECT * FROM "candied" WHERE "almonds"::field >51
name: candied
-------------
time                   almonds  almonds_1  half_almonds
2016-06-07T16:40:20Z55       true       56

指定key是tag

> SELECT * FROM "candied" WHERE "almonds"::tag='true'
name: candied
-------------
time                   almonds  almonds_1  half_almonds
2016-06-07T16:40:10Z50       true       51
2016-06-07T16:40:20Z55       true       56

如何跨measurement查詢資料？

目前，無法跨measurement執行數學運算或分組。所有資料必須在同一個measurement下，才能一起查詢這些資料。TSDB For InfluxDB®不是一個關係型資料庫，跨measurement映射資料目前不是一個推薦的Schema。

時間戳記的順序是否重要？

不重要。測試結果表明TSDB For InfluxDB®完成以下查詢所需的時間差別非常小：

SELECT ... FROM ... WHERE time >'timestamp1' AND time <'timestamp2'
SELECT ... FROM ... WHERE time <'timestamp2' AND time >'timestamp1'

如何`SELECT`有tag但沒有tag value的資料？

使用''指定一個空的tag value。例如：

> SELECT * FROM "vases" WHERE priceless=''
name: vases
-----------
time                   origin   priceless
2016-07-20T18:42:00Z8

資料寫入

為什麼寫入抖動會周期性發生？

TSDB For InfluxDB®進行分區切換時會產生寫入抖動，可以觀察抖動周期是否和保留原則的shard group duration相同。您可以通過減少measurement數量和時間軸數量來減小抖動的幅度。

行協議寫入注意事項

行協議寫入存在如下注意點：

在數字後面加上i來指定整數，如value=100i是整數，value=100是浮點數。
只在字串類型的field value中使用雙引號，measurement、tag key、tag value和field key中的雙引號將被當做名字的一部分來處理。
應該用反斜線轉義特殊字元，而不是用引號將其括起來。

為什麼資料寫入後，卻不可見？

InfluxDB會根據保留原則丟棄到期資料，在寫入過程中，可能會遇到類似partial write: points beyond retention policy的報錯資訊，建議自查寫入時間戳記和保留原則中設定的TTL。

磁碟空間滿導致寫入失敗，空間下降後寫入沒有恢複？

InfluxDB磁碟寫滿後，會導致寫入失敗，即使空間下降後還是會寫入失敗。請適當擴容或者清理資料後手動在控制台重啟進程來恢複寫入。

如何寫入整型的field value？

當寫入整數時，在field value末尾加上i。如果您不加上i，TSDB For InfluxDB®會把field value當作浮點數。

寫入整數：value=100i寫入浮點數：value=100。

TSDB For InfluxDB®如何處理重複資料點？

measurement的名字、tag set和時間戳記唯一標識一個資料點。如果您提交的資料點跟已有的資料點相比，具有相同measurement、tag set和時間戳記，但具有不同field set，那麼該資料點的field set會變為舊field set和新field set的並集，如果有任何衝突以新field set為準。這是預期的結果。

例如：

舊資料點：cpu_load,hostname=server02,az=us_west val_1=24.5,val_2=7 1234567890000000

新資料點：cpu_load,hostname=server02,az=us_west val_1=5.24 1234567890000000

當您提交新資料點後，TSDB For InfluxDB®使用新的field value覆蓋val_1的值，val_2的值繼續保留：

> SELECT * FROM "cpu_load" WHERE time =1234567890000000
name: cpu_load
--------------
time                      az        hostname   val_1   val_2
1970-01-15T06:56:07.89Z   us_west   server02   5.247

為了儲存這兩個資料點，可以：

引入新的tag保證唯一性。
舊資料點：cpu_load,hostname=server02,az=us_west,uniq=1 val_1=24.5,val_2=7 1234567890000000
新資料點：cpu_load,hostname=server02,az=us_west,uniq=2 val_1=5.24 1234567890000000
將新資料點寫入TSDB For InfluxDB®後：
```
> SELECT * FROM "cpu_load" WHERE time =1234567890000000
name: cpu_load
--------------
time                      az        hostname   uniq   val_1   val_2
1970-01-15T06:56:07.89Z   us_west   server02   124.57
1970-01-15T06:56:07.89Z   us_west   server02   25.24
```

時間戳記增加一納秒。

舊資料點：cpu_load,hostname=server02,az=us_west val_1=24.5,val_2=7 1234567890000000

新資料點：cpu_load,hostname=server02,az=us_west val_1=5.24 1234567890000001

將新資料點寫入TSDB For InfluxDB®後：

> SELECT * FROM "cpu_load" WHERE time >=1234567890000000 and time <=1234567890000001
name: cpu_load
--------------
time                             az        hostname   val_1   val_2
1970-01-15T06:56:07.89Z          us_west   server02   24.57
1970-01-15T06:56:07.890000001Z   us_west   server02   5.24

HTTP API需要怎樣的分行符號？

TSDB For InfluxDB®的行協議依賴分行符號（\n，這是ASCII 0x0A）來表示一行的結束和新的一行的開始。檔案或資料使用\n以外的分行符號會導致以下錯誤：bad timestamp, unable to parse。

請注意，Windows使用斷行符號鍵和分行符號（\r\n）作為分行符號。

當將資料寫入TSDB For InfluxDB®時，應該避免哪些文字和字元？

InfluxQL關鍵字
如果您使用InfluxQL關鍵字作為標識符，您需要在每個查詢中使用雙引號將該標識符括起來。如果不使用雙引號，會導致錯誤。標識符是連續查詢名字、資料庫名字、field key、measurement的名字、保留原則名字、tag key和使用者名稱。
時間
關鍵字time是一個特例。time可以是一個連續查詢名字、資料庫名字、measurement的名字、保留原則名字和使用者名稱。在這些情況下，不需要在查詢中用雙引號將time括起來。time不能是field key或tag key；TSDB For InfluxDB®拒絕寫入將time作為field key或tag key的資料，對於這種資料寫入，TSDB For InfluxDB®會返回錯誤。樣本如下：
- 將time作為measurement，寫入資料並查詢它。
```
> INSERT time value=1

> SELECT * FROM time

name: time
time                            value
---------
2017-02-07T18:28:27.349785384Z1
```
  在TSDB For InfluxDB®中，time是一個有效measurement名字。
- 將time作為field key，寫入資料並嘗試查詢它
```
> INSERT mymeas time=1
ERR:{"error":"partial write: invalid field name: input field \"time\" on measurement \"mymeas\" is invalid dropped=1"}
```
  在TSDB For InfluxDB®中，time不是一個有效field key。系統無法寫入該資料點，並且返回400錯誤。
- 將time作為tag key，寫入資料並嘗試查詢它。
```
> INSERT mymeas,time=1 value=1
ERR:{"error":"partial write: invalid tag key: input tag \"time\" on measurement \"mymeas\" is invalid dropped=1"}
```
  在TSDB For InfluxDB®中，time不是一個有效tag key。系統無法寫入該資料點，並且返回400錯誤。
字元
為了保持簡單的Regex和引號，避免在標識符中使用以下字元：\ 反斜線^ 尖號$ 貨幣符號' 單引號" 雙引號= 等號, 逗號。

當寫入資料時，什麼時候應該使用單引號，什麼時候應該使用雙引號？

通過行協議寫入資料時，避免使用單引號和雙引號將標識符括起來；請查看下面的樣本，使用引號後的標識符會使查詢變得複雜。標識符是連續查詢名字、資料庫名字、field key、measurement的名字、保留原則名字、subscription的名字、tag key和使用者名稱。
- 寫入帶雙引號的measurement：INSERT "bikes" bikes_available=3適用的查詢：SELECT * FROM "\"bikes\""
- 寫入帶單引號的measurement：INSERT 'bikes' bikes_available=3適用的查詢：SELECT * FROM "\'bikes\'"
- 寫入不帶引號的measurement：INSERT bikes bikes_available=3適用的查詢：SELECT * FROM "bikes"
用雙引號將字串類型的field value括起來。
寫入：INSERT bikes happiness="level 2"適用的查詢：SELECT * FROM "bikes" WHERE "happiness"='level 2'
應該用反斜線轉義特殊字元，而不是用引號將其括起來。
寫入：INSERT wacky va\"ue=4適用的查詢：SELECT "va\"ue" FROM "wacky"

時間戳記的精度是否重要？

重要。為了最大限度地提高效能，向TSDB For InfluxDB®寫入資料時盡量使用最粗糙的時間精度。

在下面兩個例子中，第一個請求使用預設精度（納秒），而第二個請求將精度設定為秒：

curl -i -XPOST "https://<網路地址>:3242/write?db=weather&u=<帳號名稱>&p=<密碼>"--data-binary 'temperature,location=1 value=90 1472666050000000000'

curl -i -XPOST "https://<網路地址>:3242/write?db=weather&precision=s&u=<帳號名稱>&p=<密碼>"--data-binary 'temperature,location=1 value=90 1472666050'

雖然效能會提高，但是代價是精度越粗糙，越有可能出現具有相同時間戳記的重複資料點，可能會覆蓋其它資料點。

命令列介面（Influx CLI）

為什麼無法使用命令列介面串連TSDB For InfluxDB®？

請逐一確認是否已滿足以下條件：

必須有可執行許可權，您可以執行chmod +x ./influx添加許可權。
串連語句中必須指定-ssl選項。
-host選項後只需指定串連串，例如ts-bp17j28j2y7pm****.influxdata.rds.aliyuncs.com，不需要添加協議和連接埠號碼。

如何使TSDB For InfluxDB®的Influx CLI返回使用者可讀的時間戳記？

在您首次串連Influx CLI時，請指定rfc3339精度：

$ influx -ssl -username <帳號名稱>-password <密碼>-host <網路地址>-port 3242-precision rfc3339

或者，在串連Influx CLI後指定精度：

$ influx -ssl -username <帳號名稱>-password <密碼>-host <網路地址>-port 3242
Connected to https://<網路地址>:3242 version 1.7.x
> precision rfc3339

詳情請參見命令列介面（Influx CLI）。

非admin使用者如何使用`USE`指定一個資料庫？

如果非admin使用者擁有資料庫的READ和WRITE，或僅有READ許可權，那麼可以執行USE <database_name>語句。如果非admin使用者嘗試用USE指定一個他們沒有READ和WRITE，或沒有READ許可權的資料庫，那麼系統會返回錯誤：

ERR:Database<database_name> doesn't exist. Run SHOW DATABASES for a list of existing databases.

說明

SHOW DATABASES查詢只返回那些非admin使用者有READ或WRITE許可權的資料庫。

如何使用TSDB For InfluxDB®的Influx CLI將資料寫入一個非預設的保留原則？

請使用文法INSERT INTO [<database>.]<retention_policy> <line_protocol>將資料寫入一個非預設的保留原則。（只允許在Influx CLI中使用這種方式指定資料庫和保留原則。如果通過HTTP寫入資料，必須使用參數db和rp分別指定資料庫和保留原則，指定保留原則是可選的。）樣本如下。

> INSERT INTO one_day mortality bool=true
Using retention policy one_day
> SELECT * FROM "mydb"."one_day"."mortality"
name: mortality
---------------
time                             bool
2016-09-13T22:29:43.229530864Z   true

您需要完全限定measurement來查詢非預設保留原則中的資料。使用以下文法完全限定measurement：

"<database>"."<retention_policy>"."<measurement>"

資料類型

為什麼不能查詢布爾類型的field value？

寫入和查詢布爾值的文法不一樣。

布爾值文法	寫入	查詢
`t`,`f`	√	❌
`T`,`F`	√	❌
`true`,`false`	√	√
`True`,`False`	√	√
`TRUE`,`FALSE`	√	√

例如：SELECT * FROM "hamlet" WHERE "bool"=True返回所有bool等於TRUE的資料點，但是，SELECT * FROM "hamlet" WHERE "bool"=T不會返回任何結果。

TSDB For InfluxDB®如何處理多個Shard之間的field的類型差異？

field value可以是浮點數、整數、字串或者布爾值。在一個Shard中，field value的資料類型需要保持統一，但是在不同的Shard，field value的資料類型可以不同。

SELECT語句
SELECT語句返回預設所有相同資料類型的field value，如果在不同的Shard裡面field value的資料類型不一樣，那麼TSDB For InfluxDB®首先會執行類型轉換（如果適用的話），然後返回所有值，並且按以下資料類型的順序返回結果：浮點數，整數，字串，布爾值。如果在您的資料中，field value的類型不同，請使用文法<field_key>::<type>查詢不同的資料類型。樣本如下：
measurement just_my_type有一個名為my_field的field，my_field在四個不同的Shard中有四個field value，並且每個field value的資料類型不一樣（分別是浮點數、整數、字串和布爾值）。
SELECT只返回浮點型和整型的field value。在返回結果中TSDB For InfluxDB®強制將整數轉換成浮點數。
```
> SELECT * FROM just_my_type

name: just_my_type
------------------
time                      my_field
2016-06-03T15:45:00Z9.87034
2016-06-03T16:45:00Z7
```
SELECT <field_key>::<type> [...]返回所有資料類型。TSDB For InfluxDB®將每種類型的資料輸出到單獨的列中，並且使用遞增的列名表示。在可能的情況下，TSDB For InfluxDB®將field value轉換成另一種資料類型；它將整數7轉換成第一列中的浮點數，將浮點數9.879034轉換成第二列中的整數。TSDB For InfluxDB®不能將浮點數或整數轉換成字串或布爾值。
```
> SELECT "my_field"::float,"my_field"::integer,"my_field"::string,"my_field"::boolean FROM just_my_type

name: just_my_type
------------------
time                   my_field  my_field_1  my_field_2  my_field_3
2016-06-03T15:45:00Z9.870349
2016-06-03T16:45:00Z77
2016-06-03T17:45:00Z                         a string
2016-06-03T18:45:00Z                                     true
```
SHOW FIELD KEYS查詢
SHOW FIELD KEYS返回field key對應的每個shard中的每種資料類型。樣本如下：
measurement just_my_type有一個名為my_field的field，my_field在四個不同的shard中有四個field value，並且每個field value的資料類型不一樣（分別是浮點數、整數、字串和布爾值）。
SHOW FIELD KEYS返回所有四種資料類型：
```
> SHOW FIELD KEYS

name: just_my_type
fieldKey   fieldType
-----------------
my_field   float
my_field   string
my_field   integer
my_field   boolean
```

TSDB For InfluxDB®可以儲存的最小和最大整數是多少？

TSDB For InfluxDB®將所有整數儲存為有符號的int64資料類型。int64有效最小和最大值分別是-9023372036854775808和9023372036854775807。請查看Go builtins獲得更多相關資訊。

使用接近最小/最大整數但依舊在限制範圍內的值可能會導致非預期的結果；有些函數和運算子會在計算過程中將資料類型int64轉換成float64，這會引起溢出問題。

TSDB For InfluxDB®可以儲存的最小和最大時間戳記是多少？

最小的時間戳記是-9223372036854775806或1677-09-21T00:12:43.145224194Z，最大的時間戳記是9223372036854775806或2262-04-11T23:47:16.854775806Z。超出該範圍的時間戳記會返回解析錯誤。

如何知道儲存在field中的資料類型？

SHOW FIELD KEYS查詢還返回field的資料類型。

> SHOW FIELD KEYS FROM all_the_types
name: all_the_types
-------------------
fieldKey  fieldType
blue      string
green     boolean
orange    integer
yellow    float

是否可以改變field的資料類型？

目前，在改變field的資料類型上面，TSDB For InfluxDB®提供非常有限的支援。文法<field_key>::<type>支援將field value從整數轉換為浮點數或者從浮點數轉換為整數。請查看文檔資料探索獲得更多關於轉換操作的資訊。無法將浮點數或整數轉換為字串或布爾值（反之亦然）。

我們列出了可用於更改field資料類型的方法：

將資料寫入一個不同的field
最簡單的解決方案就是將具有新資料類型的資料寫入到同一個序列中的不同field。
使用shard系統
在一個shard裡面，field value的資料類型不能不一樣，但是在不同的shard，field value的資料類型可以不同。
如果要更改field的資料類型，使用者可以使用SHOW SHARDS查詢來識別當前shard的end_time。如果資料點的時間戳記發生在end_time之後，那麼TSDB For InfluxDB®允許將不同資料類型的資料寫入到一個現有的field中（例如，field原來接受整數，但是在end_time之後，該field可以接受浮點數）。
請注意，這不會改變原來shard裡面field的資料類型。

InfluxQL函數

如何執行函數中的數學運算？

目前，TSDB For InfluxDB®不支援函數內的數學運算。我們建議使用子查詢作為解決方案。樣本如下：

InfluxQL不支援以下文法：

SELECT MEAN("dogs"-"cats")from"pet_daycare"

相反，我們可以使用子查詢獲得相同的結果：

> SELECT MEAN("difference") FROM (SELECT "dogs"-"cat" AS "difference" FROM "pet_daycare")

請查看資料探索獲得更多關於子查詢的資訊。

為什麼查詢將epoch 0作為時間戳記返回？

在TSDB For InfluxDB®中，epoch 0（1970-01-01T00:00:00Z）通常用作空時間戳記（null timestamp），如果您請求的查詢中沒有時間戳記返回，例如，對於沒有規定時間範圍的彙總函式，TSDB For InfluxDB®返回epoch 0作為時間戳記。

哪些InfluxQL函數支援嵌套使用？

以下InfluxQL函數支援嵌套使用：

COUNT()嵌套DISTINCT()
CUMULATIVE_SUM()
DERIVATIVE()
DIFFERENCE()
ELAPSED()
MOVING_AVERAGE()
NON_NEGATIVE_DERIVATIVE()
HOLT_WINTERS()和HOLT_WINTERS_WITH_FIT()

關於如何使用子查詢代替嵌套函數，請查看文檔資料探索。

InfluxDB資料移轉

自建InfluxDB如何上雲？

您可以通過InfluxDB官方的influx_inspect工具在自建InfluxDB伺服器上匯出行協議檔案，再使用命令列介面（Influx CLI）將檔案匯入TSDB For InfluxDB®。

如何在雲上InfluxDB不同執行個體間遷移資料？

目前尚無方案可實現InfluxDB不同執行個體間的資料移轉，您需要先查詢並匯出需遷移的資料，再手動遷移。在查詢過程中需要避免大查詢影響系統的穩定性，您可以添加時間過濾條件和時間軸過濾條件來分批遷移。

如何將InfluxDB遷移至LindormTSDB？

LindormTSDB（Lindorm時序引擎）提供了LTS工具用於匯入InfluxDB的歷史資料，您可以通過LTS將InfluxDB全量遷移至時序引擎。

問題導覽

序列和序列基數

管理（Administration）

資料查詢

資料寫入

命令列介面（Influx CLI）

資料類型

InfluxQL函數

InfluxDB資料移轉

序列和序列基數

為什麼序列基數很重要？

如何進行建模，有什麼注意事項？

管理（Administration）

關於系統穩定性需要注意什嗎？

如何查看measurement的磁碟使用量？

如何高效安全地刪除資料？

為什麼修改保留原則後不生效？

為什麼服務經常中斷？

記憶體佔用為什麼很高？是否需要升配？

儲存是否支援縮容？

雲端硬碟擴容是否會重啟？

重啟需要多長時間？

是否支援InfluxDB內建的Grafana？

為什麼訪問出現ip block錯誤？

如何識別TSDB For InfluxDB®的版本？

Shard Group Duration和保留原則之間的關係是什嗎？

當更改保留原則後，為什麼資料沒有丟失？

為什麼TSDB For InfluxDB®無法解析微秒單位？

資料查詢

如何排查慢查詢的原因？

什麼決定了GROUP BY time()查詢返回的時間間隔？

為什麼查詢沒有返回任何資料或者只返回一部分資料？

為什麼GROUP BY time()查詢不返回傳生在now()之後的時間戳記？

是否可以對時間戳記執行數學運算？

是否可以從返回的時間戳記中識別寫入精度？

當查詢資料時，什麼時候應該使用單引號，什麼時候應該使用雙引號？

為什麼在建立一個新的預設（DEFAULT）保留原則後會遺失資料？

為什麼帶有WHERE OR時間子句的查詢返回空結果？

為什麼fill(previous)返回空結果？

為什麼INTO查詢會遺失資料？

如何查詢tag key和field key名字相同的資料？

如何跨measurement查詢資料？

時間戳記的順序是否重要？

如何SELECT有tag但沒有tag value的資料？

資料寫入

為什麼寫入抖動會周期性發生？

行協議寫入注意事項

為什麼資料寫入後，卻不可見？

磁碟空間滿導致寫入失敗，空間下降後寫入沒有恢複？

如何寫入整型的field value？

TSDB For InfluxDB®如何處理重複資料點？

HTTP API需要怎樣的分行符號？

當將資料寫入TSDB For InfluxDB®時，應該避免哪些文字和字元？

當寫入資料時，什麼時候應該使用單引號，什麼時候應該使用雙引號？

時間戳記的精度是否重要？

命令列介面（Influx CLI）

為什麼無法使用命令列介面串連TSDB For InfluxDB®？

如何使TSDB For InfluxDB®的Influx CLI返回使用者可讀的時間戳記？

非admin使用者如何使用USE指定一個資料庫？

如何使用TSDB For InfluxDB®的Influx CLI將資料寫入一個非預設的保留原則？

資料類型

為什麼不能查詢布爾類型的field value？

TSDB For InfluxDB®如何處理多個Shard之間的field的類型差異？

TSDB For InfluxDB®可以儲存的最小和最大整數是多少？

TSDB For InfluxDB®可以儲存的最小和最大時間戳記是多少？

如何知道儲存在field中的資料類型？

是否可以改變field的資料類型？

InfluxQL函數

如何執行函數中的數學運算？

為什麼查詢將epoch 0作為時間戳記返回？

哪些InfluxQL函數支援嵌套使用？

InfluxDB資料移轉

自建InfluxDB如何上雲？

如何在雲上InfluxDB不同執行個體間遷移資料？

如何將InfluxDB遷移至LindormTSDB？

為什麼訪問出現`ip block`錯誤？

什麼決定了`GROUP BY time()`查詢返回的時間間隔？

為什麼`GROUP BY time()`查詢不返回傳生在`now()`之後的時間戳記？

為什麼在建立一個新的預設（`DEFAULT`）保留原則後會遺失資料？

為什麼帶有`WHERE OR`時間子句的查詢返回空結果？

為什麼`fill(previous)`返回空結果？

為什麼`INTO`查詢會遺失資料？

如何`SELECT`有tag但沒有tag value的資料？

非admin使用者如何使用`USE`指定一個資料庫？