全部產品
Search

搜尋本產品

    Time Series Database：FAQ

    文件中心

    Time Series Database：FAQ

    更新時間：Jul 06, 2024

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

    管理（Administration）

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

    • shard group duration和保留原則之間的關係是什嗎？

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

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

    命令列介面（CLI）

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

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

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

    資料類型

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

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

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

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

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

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

    InfluxQL函數

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

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

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

    查詢資料

    • 什麼決定了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®時，應該避免哪些文字和字元？

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

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

    如何識別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®通過查看相關保留原則的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®命令列介面（CLI）設定精度，用於指定微秒時間單位的文法也不同。下表顯示了每個類別支援的文法：

    使用HTTP API寫入資料

    所有查詢

    在CLI設定精度

    u

    √

    √

    √

    us

    ❌

    ❌

    ❌

    µ

    ❌

    √

    ❌

    µs

    ❌

    ❌

    ❌

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

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

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

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

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

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

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

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

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

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

    請使用文法INSERT INTO [<database>.]<retention_policy> <line_protocol>將資料寫入一個非預設的保留原則。（只允許在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的資料類型。

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

    目前，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()

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

    什麼決定了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®維護系統中每個序列在記憶體中的索引。隨著序列數量不斷增加，RAM（記憶體）使用量也在不斷增加。序列基數過大會導致作業系統終止TSDB For InfluxDB®進程，並拋出記憶體不足（OOM）異常。

    如何寫入整型的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'

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