TSDB for InfluxDB よくある質問 - シリーズカーディナリティ、クエリ、管理、移行 - Time Series Database

TSDB for InfluxDB® のシリーズカーディナリティ、管理、データクエリ、書き込み、CLI の使用、データ型、InfluxQL 関数、移行に関するよくある質問について説明します。

よくある質問

シリーズとシリーズカーディナリティ

シリーズカーディナリティの重要性

TSDB for InfluxDB® は、シリーズごとにメモリ内インデックスを保持します。シリーズ数が増加するにつれて、RAM の使用量も増加します。カーディナリティが過度に高くなると、メモリ不足 (OOM) 例外が発生し、プロセスが終了する可能性があります。「InfluxQL Reference」

モデリング方法と注意点

時系列の数は 100 万未満に抑えてください。大規模な時系列シナリオの場合は、「LindormTSDB の概要」をご参照ください。InfluxDB のスキーマおよびデータレイアウトガイドを確認してください。InfluxDB はタグにインデックスを付けてクエリを高速化しますが、タグが多すぎるとシリーズが膨張し、読み書きが低速になります。主な考慮事項：

ID、ハッシュ値、ランダムな文字列など、カーディナリティの高い値を持つタグの使用は避けてください。
メジャーメント名やタグ名にデータを格納しないでください。データはタグとフィールドに格納してください。
1 つのタグに複数の情報を格納しないでください。情報は複数のタグに分割してください。
GROUP BY 句でフィールドを頻繁に使用する場合は、そのフィールドをタグとしてモデリングしてください。

管理

システムの安定性維持に関する注意点

メモリ使用量を 80% 未満に保ってください。
時系列の数を 100 万未満に抑えてください。モデリングの注意事項に従ってスキーマを計画してください。
メジャメントの数を制御してください。モデリングの注意事項のガイドラインに従ってください。
データ量を制御してください。保持ポリシーを設定して、古いデータを定期的に削除してください。
適切なシャードグループ期間を設定し、保持ポリシーを設定して古いシャードを削除してください。

メジャメントのディスク使用量の確認方法

ディスク使用量はメジャメントレベルでは表示できません。メジャメントは論理的な概念であり、同じデータベース内のすべてのメジャメントは、基盤となるデータファイルを共有します。

効率的かつ安全なデータ削除方法

InfluxDB の drop measurement、drop series、および delete 操作は論理削除を実行しますが、これには以下の欠点があります。

InfluxDB 1.x では、コード実装レベルでデッドロックが発生する可能性があります。
クエリは削除された時系列を除外する必要があり、クエリ効率に深刻な影響を与えます。
論理削除ではディスク領域をすぐに解放できません。バックグラウンドのデータマージスケジューリングを待つ必要があり、領域の解放が遅くなります。

保持ポリシーを変更して古いデータを削除するか、drop shard または drop database を使用して物理削除を実行してください。

変更した保持ポリシーが有効にならない原因

v1.8.13 以降では、保持ポリシーの変更はすぐに有効になります。変更が有効にならない場合は、以下を確認してください。

バージョンが v1.8.12 以前かどうかを確認してください。以前のバージョンでは、保持ポリシーの変更にはバックグラウンドスケジューリングが必要です。30 分から 60 分お待ちください。
シャードが広範な時間範囲をカバーしています。show shards を実行して確認してください。シャードは、現在の時刻がシャードの終了時刻を超えた後にのみ削除できます。

サービスが頻繁に中断される原因

メモリ使用量を確認してください。80% を超えると、OOM エラーによってプロセスが停止する可能性があります。よくある質問：メモリ使用量が高いのはなぜですか？を参照して原因を特定するか、インスタンスをアップグレードしてください。

メモリ使用量が高い原因とアップグレードの要否

メモリ使用量が高くなる一般的な原因は次のとおりです。

多数の時系列。インデックスのマージは大量のメモリを消費します。シリーズ数を 100 万未満に抑えてください。大規模な時系列シナリオの場合は、LindormTSDB の概要をご検討ください。
大量のデータまたは多数のシャード。データが増えると、ファイルマージによるメモリ負荷が増加し、再起動時間が長くなります。よくある質問：効率的かつ安全にデータを削除するにはどうすればよいですか？に従ってデータを削減してください。大規模ストレージの場合は、LindormTSDB の概要をご検討ください。
大規模なクエリ。大規模なクエリは避けてください。タグと時間フィルターを追加して、スキャン範囲を削減してください。
クエリに Grafana を使用する場合、Grafana がチャートの設定時に show tag keys クエリを発行することがあり、これが OOM エラーを引き起こす可能性があります。v1.8.13 以降にアップグレードして show tag keys クエリを無効にしてください。

それでもメモリ使用量が 80% を超える場合は、 インスタンスをアップグレード してください。インスタンスのアップグレードまたはダウングレードをご参照ください。

ストレージのスケールインのサポート

InfluxDB のディスクは スケールインをサポートしていません。

ディスク拡張時の再起動の有無

ディスクを拡張すると、InfluxDB プロセスが再起動します。Basic Edition インスタンスは短時間利用できなくなる可能性があります。高可用性エディションのインスタンスはローリング再起動を実行するため、通常はビジネスへの影響はありません。

再起動にかかる時間

再起動時間はデータ量に依存します。データ量が多いほど、再起動に時間がかかります。

InfluxDB 向け組み込み Grafana のサポート

代わりに Alibaba Cloud の Managed Service for Grafana を使用してください。InfluxDB 向けの組み込み Grafana は古く、現在はメンテナンスされていません。

アクセス時に `IP ブロック` エラーが表示されるのはなぜですか。

v1.8.12 以前のバージョンでは、パスワードの試行に何度も失敗すると、一時的に IP アドレスがブロックされます。v1.8.13 以降にアップグレードしてください。

TSDB for InfluxDB® のバージョンの特定方法

以下のいずれかの方法を使用してください。

curl /ping

$ curl -i 'https://<endpoint>:3242/ping?u=<username>&p=<password>'
HTTP/1.1 204 No Content
Content-Type: application/json
X-Influxdb-Build: OSS
X-Influxdb-Version: 1.7.x

TSDB for InfluxDB® のコマンドラインインターフェイスを起動する

$ influx -ssl -username <username> -password <password> -host <endpoint> -port 3242

Connected to https://<endpoint>:3242 version 1.7.x

シャードグループ期間と保持ポリシーの関係

TSDB for InfluxDB® は、データをシャードグループに保存します。シャードグループは特定の時間間隔をカバーします。TSDB for InfluxDB® は、関連する保持ポリシー (RP) の DURATION を確認して時間間隔を決定します。次の表は、RP の DURATION とシャードグループの時間間隔のデフォルトの関係を示しています。

RP 期間	シャードグループの時間間隔
< 2 日	1 時間
>= 2 日かつ <= 6 か月	1 日
> 6 か月	7 日

SHOW RETENTION POLICIES を使用して、保持ポリシーのシャードグループ期間を表示してください。

保持ポリシーを変更してもデータが失われない原因

保持ポリシーを変更した直後にデータが失われない理由は次のとおりです。

最初の考えられる理由 (最も可能性の高いシナリオ) ：デフォルトでは、TSDB for InfluxDB® は 30 分ごとに RP をチェックして適用します。TSDB for InfluxDB® が RP の新しい DURATION の範囲外のデータを削除する前に、次の RP チェックを待つ必要がある場合があります。
2 つ目の考えられる理由：RP の DURATION と SHARD DURATION を変更すると、予期しないデータ保持につながる可能性があります。TSDB for InfluxDB® はデータをシャードグループに保存します。各シャードグループは、特定の RP と時間間隔をカバーします。TSDB for InfluxDB® が RP を適用すると、個々のデータポイントではなく、シャードグループ全体が削除されます。TSDB for InfluxDB® はシャードグループを分割できません。RP の新しい DURATION が古い SHARD DURATION よりも短い場合、TSDB for InfluxDB® がより長い DURATION を持つ古いシャードグループにデータを書き込んでいると、システムはそのシャードグループにすべてのデータを保存せざるを得なくなります。これは、シャードグループ内の一部のデータが新しい DURATION の範囲外であっても発生します。シャードグループ内のすべてのデータが新しい DURATION の範囲外になると、TSDB for InfluxDB® はシャードグループ全体を削除します。その後、システムは新しい、より短い SHARD DURATION を持つシャードグループへのデータ書き込みを開始します。これにより、さらなる予期しないデータ保持が回避されます。

TSDB for InfluxDB® におけるマイクロ秒単位の構文

マイクロ秒の時間単位を指定する構文は、TSDB for InfluxDB® コマンドラインインターフェイス (Influx CLI) での書き込み、クエリ、および精度の設定で異なります。次の表は、各カテゴリでサポートされている構文を示しています。

	HTTP API を使用したデータ書き込み	すべてのクエリ	Influx CLI での精度の設定
u	√	√	√
us	❌	❌	❌
µ	❌	√	❌
µs	❌	❌	❌

データクエリ

スロークエリのトラブルシューティング

スロークエリは通常、スキャンする時系列または生データが多すぎることが原因です。すべてのクエリにタグと時間範囲のフィルターを追加してください。 EXPLAIN ANALYZE コマンドを使用してパフォーマンスを診断します。execution_time はデータの読み取りと計算を、planning_time は時系列のスキャンを反映します。

`GROUP BY time()` クエリで返される時間間隔の決定要因

GROUP BY time() クエリで返される時間間隔は、TSDB for InfluxDB® のプリセットタイムバケット、またはユーザー指定のオフセット間隔に一致します。次の例をご参照ください：

プリセットタイムバケット

次のクエリは、午後 6:15 から午後 7:45 までの sunflowers の平均を計算し、平均を 1 時間単位でグループ化します：
```
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® がプリセットタイムバケットを維持する仕組みを示しています。

この例では、午後 6 時がプリセットタイムバケットであり、午後 7 時もプリセットタイムバケットです。WHERE 句ではクエリの時間範囲を指定しているため、午後 6 時のタイムバケットの平均を計算する際に、午後 6:15 より前のデータは含まれません。ただし、午後 6 時のタイムバケットの平均計算に使用されるデータは、午後6時台に発生したものである必要があります。午後 7 時のタイムバケットについても同様です。午後 7 時のタイムバケットの平均計算に使用されるデータは、午後7時台に発生したものである必要があります。破線は、各平均の計算に使用されるデータポイントを示しています。

結果の最初のタイムスタンプは 2016-08-29T18:00:00Z ですが、そのタイムバケットのクエリ結果には、WHERE 句で指定した開始時刻である 2016-08-29T18:15:00Z より前に発生したデータは含まれないことに注意してください。

生データ：
```
name: flower_orders                                name: flower_orders
—————————-------------------
time                    sunflowers                 time                  mean
2016-08-29T18:00:00Z    34                         2016-08-29T18:00:00Z    22.332
|--|                                               2016-08-29T19:00:00Z    62.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:00Z    70
```

オフセット間隔

次のクエリは、午後 6:15 から午後 7:45 までの sunflowers の平均を計算し、平均を 1 時間単位でグループ化します。また、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 分シフトします。これにより、午後 6 時のタイムバケットの平均には午後 6:15 から午後 7:15 までのデータが含まれます。午後 7 時のタイムバケットの平均には午後 7:15 から午後 8:15 までのデータが含まれます。破線は、各平均の計算に使用されるデータポイントを示しています。

結果の最初のタイムスタンプは、2016-08-29T18:00:00Z ではなく 2016-08-29T18:15:00Z になることに注意してください。

生データと結果：

name: flower_orders                                name: flower_orders
—————————-------------------
time                    sunflowers                 time                  mean
2016-08-29T18:00:00Z    34                         2016-08-29T18:15:00Z    30.75
|--|                                               2016-08-29T19:15:00Z    65
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 に保存されていない場合、使用する RP を明示的に指定しない限り、TSDB for InfluxDB® は結果を返しません。
SELECT 句内のタグキー

クエリでデータを返すには、SELECT 句に少なくとも 1 つのフィールドキーを含める必要があります。SELECT 句に 1 つ以上のタグキーのみが含まれている場合、クエリは空の結果を返します。詳細については、「Data exploration」をご参照ください。
クエリの時間範囲

別の可能性として、クエリの時間範囲が考えられます。デフォルトでは、ほとんどの SELECT クエリは、UTC の 1677-09-21 00:12:43.145224194 から UTC の 2262-04-11T23:47:16.854775806Z までの時間範囲を対象とします。一方、GROUP BY time() 句を含む SELECT クエリの対象範囲は、1677-09-21 00:12:43.145224194 から now() までです。データが now() より後に発生している場合、GROUP BY time() クエリでは now() より後のデータは対象になりません。クエリ文に GROUP BY time() 句を含み、now() より後に発生するデータがある場合は、時間範囲の上限を指定する必要があります。
識別子名

最後の一般的な理由は、フィールドキーとタグキーが同じ名前であるスキーマに関連するものです。フィールドキーとタグキーが同一の場合、すべてのクエリでフィールドが優先されます。クエリでは、::tag 構文を使用してタグキーを指定する必要があります。

`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() までのタイムスタンプのデータを対象とします。2 つ目のクエリは 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)

デフォルトの上限である now() を上書きするには、WHERE 句で時間範囲の上限を指定する必要があることに注意してください。次のクエリは下限を now() にリセットするだけのため、クエリの時間範囲が now() から now() までになります：

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

時間構文の詳細については、「Data exploration」をご参照ください。

タイムスタンプに対する数学演算

TSDB for InfluxDB® は、タイムスタンプに対する数学演算をサポートしていません。時間計算はクライアント側で実行してください。

TSDB for InfluxDB® は、タイムスタンプに対する InfluxQL 関数の使用を限定的にサポートしています。ELAPSED() 関数は、単一フィールド内のタイムスタンプ間の差分を返します。

返されたタイムスタンプからの書き込み精度の特定

TSDB for InfluxDB® は、書き込み精度にかかわらず、すべてのタイムスタンプをナノ秒で保存します。データベースは返されたタイムスタンプの末尾のゼロを暗黙的に削除するため、元の書き込み精度を特定しにくくなります。

次の例では、タグ precision_supplied と timestamp_supplied が、データ書き込み時にユーザーが指定した時間精度とタイムスタンプを示しています。TSDB for InfluxDB® は返されたタイムスタンプの末尾のゼロを暗黙的に削除するため、返されたタイムスタンプから書き込み精度を特定することは困難です。

name: trails
-------------
time                  value  precision_supplied  timestamp_supplied
1970-01-01T01:00:00Z  3      n                   3600000000000
1970-01-01T01:00:00Z  5      h                   1
1970-01-01T02:00:00Z  4      n                   7200000000000
1970-01-01T02:00:00Z  6      h                   2

データクエリにおけるシングルクォーテーションとダブルクォーテーションの使い分け

タグ値などの文字列値は、シングルクォーテーションで囲みます。識別子をシングルクォーテーションで囲まないでください。識別子には、データベース名、リテンションポリシー名、ユーザー名、メジャメント名、タグキー、フィールドキーが含まれます。

識別子が数字で始まる場合、[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"

時間構文の詳細については、「Data exploration」をご参照ください。

新しい `DEFAULT` リテンションポリシーを作成した後にデータが失われる理由

データベースに新しいデフォルトのリテンションポリシー (RP) を作成した場合、古いデフォルト RP のデータは古い RP に残ります。RP を指定しないクエリは新しいデフォルト RP から自動的にデータをクエリするため、古いデータがすべて失われたように見える場合があります。古いデータをクエリするには、クエリでデータを完全修飾する必要があります。次の例をご参照ください：

メジャメント fleeting のすべてのデータは、one_hour という名前のデフォルト RP に属しています：

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

次に新しいデフォルト 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:00Z     8

`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:20Z-2016-07-12T16:50:30Z を、タイムバケット 2016-07-12T16:50:00Z-2016-07-12T16:50:10Z の値で補完しません。

サンプルデータ：

> SELECT * FROM "cupcakes"
name: cupcakes
--------------
time                   chocolate
2016-07-12T16:50:00Z   3
2016-07-12T16:50:10Z   2
2016-07-12T16:50:40Z   12
2016-07-12T16:50:50Z   11

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:40Z   12
2016-07-12T16:51:00Z   12

`INTO` クエリでデータが失われる理由

デフォルトでは、INTO クエリは、ソースデータのタグを新たに書き込まれるデータのフィールドに変換します。これにより、TSDB for InfluxDB® は、タグによって区別されていたデータポイントを上書きする場合があります。新たに書き込まれるデータでタグを保持するために、すべての INTO クエリに GROUP BY * を含めてください。

説明

この方法は TOP() または BOTTOM() クエリには適用できません。これらの関数の詳細については、「InfluxDB functions」をご参照ください。

サンプルデータ

メジャメント french_bulldogs には、タグ color とフィールド 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 クエリ

INTO クエリに GROUP BY * 句が含まれていない場合、タグ color は新たに書き込まれるデータのフィールドに変換されます。ソースデータでは、データポイント nugget と rumple はタグ color のみで区別されます。color がフィールドになると、TSDB for InfluxDB® はデータポイント nugget と rumple を重複と見なします。その結果、データポイント nugget はデータポイント rumple によって上書きされます。
```
> SELECT * INTO "all_dogs" FROM "french_bulldogs"
name: result
------------
time                  written
1970-01-01T00:00:00Z  3

> 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 クエリ

INTO クエリに GROUP BY * 句が含まれている場合、タグ color は新たに書き込まれるデータで保持されます。この場合、データポイント nugget と rumple は引き続き別々のデータポイントとして扱われ、TSDB for InfluxDB® はデータを上書きしません。

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

> 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

タグキーとフィールドキーが同名の場合のデータクエリ

キーがフィールドキーかタグキーかを指定するには、:: 構文を使用します。サンプルデータ：

> INSERT candied,almonds=true almonds=50,half_almonds=51 1465317610000000000
> INSERT candied,almonds=true almonds=55,half_almonds=56 1465317620000000000

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

キーがフィールドであることを指定

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

キーがタグであることを指定

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

メジャメントをまたいだデータクエリ

メジャメントをまたいだ数学演算やグループ化はサポートされていません。すべてのデータは同じメジャメントに存在する必要があります。TSDB for InfluxDB® はリレーショナルデータベースではないため、メジャメント間でデータをマッピングしないでください。

タイムスタンプの順序

いいえ。テスト結果では、TSDB for InfluxDB® が次のクエリを完了するまでにかかる時間の差はごくわずかであることが示されています：

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

タグ値が空のデータの選択

空のタグ値を指定するには、'' を使用します。例：

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

データ書き込み

書き込みジッターが定期的に発生するのはなぜですか？

書き込みジッターは、TSDB for InfluxDB® がパーティションを切り替えるときに発生します。ジッターの期間が保持ポリシーのシャードグループ期間と同じであるかを確認できます。メジャメントと時系列の数を減らすことで、ジッターの大きさを軽減できます。

ラインプロトコル書き込みの注意事項

ラインプロトコルによる書き込みについては、以下の点にご注意ください。

数値を整数として指定するには、末尾に i を付けます。例えば、value=100i は整数であり、value=100 は浮動小数点数です。
二重引用符は、文字列のフィールド値にのみ使用します。メジャメント、タグキー、タグ値、フィールドキー内の二重引用符は、名前の一部として扱われます。
特殊文字は、引用符で囲むのではなく、バックスラッシュでエスケープします。

書き込み後にデータが表示されないのはなぜですか？

InfluxDB は、リテンションポリシーに従って期限切れのデータを破棄します。 partial write: points beyond retention policy が表示された場合は、書き込みタイムスタンプをリテンションポリシーの TTL と照らし合わせて確認してください。

ディスク領域がいっぱいになった後、空き容量を確保しても書き込みが再開されないのはなぜですか？

InfluxDB のディスクがいっぱいになると、書き込みは失敗し、空き容量を確保した後も自動的に再開されません。スケールアウトまたはデータをクリアしてから、コンソールからプロセスを再起動してください。

整数のフィールド値を書き込むにはどうすればよいですか？

整数を書き込む際は、フィールド値の末尾に i を付けます。 i を付けないと、TSDB for InfluxDB® はそのフィールド値を浮動小数点数として扱います。

整数の書き込み： value=100i。浮動小数点数の書き込み： value=100。

TSDB for InfluxDB® は重複するデータポイントをどのように処理しますか？

データポイントは、そのメジャメント名、タグセット、およびタイムスタンプによって一意に識別されます。既存のデータポイントと同じメジャメント、タグセット、およびタイムスタンプを持つが、フィールドセットが異なるデータポイントを送信した場合、そのデータポイントのフィールドセットは、古いフィールドセットと新しいフィールドセットの和集合になります。競合が存在する場合、新しいフィールドセットが優先されます。これは期待される動作です。

例：

古いデータポイント： 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® は 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.24    7

両方のデータポイントを保存するには、次の方法があります。

一意性を確保するために新しいタグを導入します。

古いデータポイント： 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   1      24.5    7
1970-01-15T06:56:07.89Z   us_west   server02   2      5.24
```
タイムスタンプを 1 ナノ秒だけインクリメントします。

古いデータポイント： 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.5    7
1970-01-15T06:56:07.890000001Z   us_west   server02   5.24
```

HTTP API で必要な改行文字

TSDB for InfluxDB® のラインプロトコルでは、1 行の終わりと新しい行の始まりを示すために、改行文字 (\n、ASCII 0x0A) を使用します。\n 以外の改行文字を使用するファイルやデータでは、bad timestamp または unable to parse エラーが発生します。

Windows では \r\n (キャリッジリターン + ラインフィード) が使用されており、これには互換性がありません。

TSDB for InfluxDB® へのデータ書き込み時に避けるべき単語と文字

InfluxQL キーワード

InfluxQL キーワードを識別子として使用する場合、すべてのクエリでその識別子を二重引用符で囲む必要があります。二重引用符を使用しないとエラーが発生します。識別子とは、継続クエリ名、データベース名、フィールドキー、メジャメント名、保持ポリシー名、タグキー、およびユーザー名です。
Time

キーワード time は特殊なケースです。time は、継続クエリ名、データベース名、メジャメント名、リテンションポリシー名、およびユーザー名にすることができます。これらのケースでは、クエリで time をダブルクォーテーションマークで囲む必要はありません。time はフィールドキーまたはタグキーにすることはできません。TSDB for InfluxDB® は、time をフィールドキーまたはタグキーとして使用するデータの書き込みを拒否します。このような書き込みに対して、TSDB for InfluxDB® はエラーを返します。次の例をご参照ください。
- time をメジャメントとしてデータを書き込み、クエリする。
```
> INSERT time value=1

> SELECT * FROM time

name: time
time                            value
---------
2017-02-07T18:28:27.349785384Z  1
```
  TSDB for InfluxDB® では、time は有効なメジャメント名です。
- time をフィールドキーとしてデータを書き込み、クエリを試みる。
```
> 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 は有効なフィールドキーではありません。システムはデータポイントを書き込むことができず、400 エラーを返します。
- time をタグキーとしてデータを書き込み、クエリを試みる。
```
> 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 は有効なタグキーではありません。システムはデータポイントを書き込むことができず、400 エラーを返します。
文字

正規表現とクォーテーションを単純に保つため、識別子に次の文字を使用することは避けてください： \ (バックスラッシュ)、^ (キャレット)、$ (ドル記号)、' (単一引用符)、" (二重引用符)、= (等号)、および , (コンマ)。

データ書き込みにおける単一引用符と二重引用符の使い分け

ラインプロトコルで書き込む際は、識別子を引用符で囲むことは避けてください。クエリが複雑になります。識別子とは、継続クエリ名、データベース名、フィールドキー、メジャメント名、保持ポリシー名、サブスクリプション名、タグキー、およびユーザー名です。
- 二重引用符でメジャメントを書き込む： INSERT "bikes" bikes_available=3。対応するクエリ： SELECT * FROM "\"bikes\""
- 単一引用符でメジャメントを書き込む： INSERT 'bikes' bikes_available=3。対応するクエリ： SELECT * FROM "\'bikes\'"
- 引用符なしでメジャメントを書き込む： INSERT bikes bikes_available=3。対応するクエリ： SELECT * FROM "bikes"
文字列のフィールド値を囲むには、二重引用符を使用します。

書き込み： INSERT bikes happiness="level 2"。対応するクエリ： SELECT * FROM "bikes" WHERE "happiness"='level 2'
特殊文字は、引用符で囲むのではなく、バックスラッシュでエスケープします。

書き込み： INSERT wacky va\"ue=4。対応するクエリ： SELECT "va\"ue" FROM "wacky"

タイムスタンプの精度の重要性

最適な書き込みパフォーマンスを得るには、できるだけ粗いタイムスタンプの精度を使用してください。

次の 2 つの例では、最初のリクエストはデフォルトの精度 (ナノ秒) を使用し、2 番目のリクエストは精度を秒に設定しています。

curl -i -XPOST "https://<endpoint>:3242/write?db=weather&u=<username>&p=<password>" --data-binary 'temperature,location=1 value=90 1472666050000000000'

curl -i -XPOST "https://<endpoint>:3242/write?db=weather&precision=s&u=<username>&p=<password>" --data-binary 'temperature,location=1 value=90 1472666050'

トレードオフとして、精度が粗いと重複するタイムスタンプの可能性が高まり、データが上書きされる原因となる場合があります。

コマンドラインインターフェイス (Influx CLI)

コマンドラインインターフェイスを使用して TSDB for InfluxDB® に接続できないのはなぜですか？

以下の項目を 1 つずつ確認してください。

実行権限が必要です。chmod +x ./influx コマンドを実行して権限を追加できます。
接続ステートメントで -ssl オプションを指定する必要があります。
-host オプションには、ts-bp17j28j2y7pm****.influxdata.rds.aliyuncs.com のような接続文字列のみを指定します。プロトコルとポート番号は追加しないでください。

TSDB for InfluxDB® の Influx CLI で、人間が判読できるタイムスタンプを返す方法

Influx CLI に初めて接続する際に、精度に rfc3339 を指定します。

$ influx -ssl -username <username> -password <password> -host <endpoint> -port 3242 -precision rfc3339

または、Influx CLI に接続した後に精度を指定することもできます。

$ influx -ssl -username <username> -password <password> -host <endpoint> -port 3242
Connected to https://<endpoint>:3242 version 1.7.x
> precision rfc3339

詳細は、「コマンドラインインターフェイス (Influx CLI)」をご参照ください。

非管理者ユーザーが `USE` を使用してデータベースを指定する方法

非管理者ユーザーがデータベースに対して READ および WRITE 権限、または READ 権限のみを持っている場合、USE <database_name> 文を実行できます。非管理者ユーザーが READ および WRITE 権限、または READ 権限を持っていないデータベースを USE で指定しようとすると、システムは次のエラーを返します。

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

説明

SHOW DATABASES クエリは、非管理者ユーザーが 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

デフォルト以外の保存ポリシーのデータをクエリするには、メジャーメントを完全修飾する必要があります。完全修飾するには、次の構文を使用します。

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

データ型

ブール値のフィールド値をクエリできない理由

ブール値の書き込みとクエリでは、構文が異なります。

ブール値の構文	書き込み	クエリ
`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® におけるシャード間のフィールド型の不一致の処理

フィールド値は、浮動小数点数、整数、文字列、またはブール値にすることができます。シャード内では、フィールド値のデータ型は一貫している必要があります。ただし、異なるシャード間では、フィールド値のデータ型が異なる場合があります。

SELECT ステートメント

SELECT 文は、デフォルトで同じデータ型のすべてのフィールド値を返します。異なるシャードでフィールド値のデータ型が同じでない場合、TSDB for InfluxDB® は、まず型変換を実行し (該当する場合)、浮動小数点数、整数、文字列、ブール値の順ですべての値を返します。データ内のフィールド値の型が異なる場合は、<field_key>::<type> 構文を使用して、異なるデータ型をクエリします。次の例をご参照ください。

メジャーメント just_my_type には my_field というフィールドがあります。my_field は、4つの異なるシャードに4つのフィールド値を持ち、各フィールド値のデータ型はそれぞれ浮動小数点数、整数、文字列、ブール値です。

SELECT は、浮動小数点と整数のフィールド値のみを返します。結果では、TSDB for InfluxDB® によって整数が浮動小数点数に強制的に変換されます。
```
> SELECT * FROM just_my_type

name: just_my_type
------------------
time                      my_field
2016-06-03T15:45:00Z      9.87034
2016-06-03T16:45:00Z      7.0
```
SELECT <field_key>::<type> [...] は、すべてのデータ型を返します。 TSDB for InfluxDB® は、各タイプのデータを別々の列に出力し、インクリメントする列名を使用します。可能な場合、TSDB for InfluxDB® はフィールド値を別のデータ型に変換します。最初の列で整数 7 を浮動小数点数に変換し、2 番目の列で浮動小数点数 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:00Z   9.87034   9
2016-06-03T16:45:00Z   7.0       7
2016-06-03T17:45:00Z                         a string
2016-06-03T18:45:00Z                                     true
```
SHOW FIELD KEYS クエリ

SHOW FIELD KEYS は、各シャードにおいてフィールドキーに対応するすべてのデータ型を返します。次の例をご参照ください。

メジャーメント just_my_type には、my_field というフィールドがあります。 my_field には 4 つの異なるシャードに 4 つのフィールド値があり、各フィールド値のデータ型は、それぞれ浮動小数点数、整数、文字列、ブール値と異なっています。

SHOW FIELD KEYS は 4 つすべてのデータ型を返します：
```
> 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 です。この範囲外のタイムスタンプは解析エラーを返します。

フィールドに保存されているデータ型を確認する方法

SHOW FIELD KEYS クエリは、フィールドのデータ型も返します。

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

フィールドのデータ型の変更

TSDB for InfluxDB® では、フィールドのデータ型の変更は、ごく限られた範囲でしかサポートされていません。構文 <field_key>::<type> を使用すると、フィールド値を整数から浮動小数点数へ、または浮動小数点数から整数へ変換できます。変換の詳細については、データ探索に記載されています。浮動小数点数または整数を文字列またはブール値に変換したり、その逆の変換を行ったりすることはできません。

フィールドのデータ型を変更する方法：

別のフィールドにデータを書き込む

最も簡単な解決策は、同じシリーズ内の別のフィールドに、新しいデータ型でデータを書き込むことです。
シャードシステムを使用する

シャード内では、フィールド値のデータ型を変えることはできません。ただし、異なるシャード間では、フィールド値のデータ型が異なる場合があります。

フィールドのデータ型を変更するには、ユーザーは SHOW SHARDS クエリを使用して、現在のシャードの end_time を特定できます。データポイントのタイムスタンプが end_time より後である場合、TSDB for InfluxDB® では、既存のフィールドに異なるデータ型のデータを書き込むことができます。たとえば、あるフィールドが元々整数を受け入れていましたが、end_time 以降、そのフィールドは浮動小数点数を受け入れることができます。

この操作では、元のシャード内のフィールドのデータ型は変更されないことに注意してください。

InfluxQL 関数

関数内で数学演算を実行する方法

TSDB for InfluxDB® は、関数内の数学演算をサポートしていません。回避策としてサブクエリを使用してください。

InfluxQL は次の構文をサポートしていません。

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

代わりに、サブクエリを使用して同じ結果を取得できます。

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

サブクエリの詳細については、「データ探索」をご参照ください。

クエリでタイムスタンプとしてエポック 0 が返される理由

TSDB for InfluxDB® では、エポック 0 (1970-01-01T00:00:00Z) が null タイムスタンプとしてよく使用されます。時間範囲が指定されていない集計関数など、タイムスタンプを返せないクエリをリクエストすると、TSDB for InfluxDB® はタイムスタンプとしてエポック 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 へのデータ移行

TSDB for InfluxDB® インスタンスから LindormTSDB への全量データの移行は、TSDB for InfluxDB® の履歴データ移行ソリューションで説明されている方法で行います。

よくある質問

シリーズとシリーズカーディナリティ

管理

データクエリ

データ書き込み

コマンドラインインターフェイス (Influx CLI)

データ型

InfluxQL 関数

InfluxDB データ移行

シリーズとシリーズカーディナリティ

シリーズカーディナリティの重要性

モデリング方法と注意点

管理

システムの安定性維持に関する注意点

メジャメントのディスク使用量の確認方法

効率的かつ安全なデータ削除方法

変更した保持ポリシーが有効にならない原因

サービスが頻繁に中断される原因

メモリ使用量が高い原因とアップグレードの要否

ストレージのスケールインのサポート

ディスク拡張時の再起動の有無

再起動にかかる時間

InfluxDB 向け組み込み Grafana のサポート

アクセス時に IP ブロック エラーが表示されるのはなぜですか。

TSDB for InfluxDB® のバージョンの特定方法

シャードグループ期間と保持ポリシーの関係

保持ポリシーを変更してもデータが失われない原因

TSDB for InfluxDB® におけるマイクロ秒単位の構文

データクエリ

スロークエリのトラブルシューティング

GROUP BY time() クエリで返される時間間隔の決定要因

クエリでデータが返されない、または一部のデータのみが返される理由

GROUP BY time() クエリで now() より後に発生するタイムスタンプが返されない理由

タイムスタンプに対する数学演算

返されたタイムスタンプからの書き込み精度の特定

データクエリにおけるシングルクォーテーションとダブルクォーテーションの使い分け

新しい DEFAULT リテンションポリシーを作成した後にデータが失われる理由

WHERE句で時間範囲にORを使用すると結果が空になる理由

fill(previous) で結果が空になる理由

INTO クエリでデータが失われる理由

タグキーとフィールドキーが同名の場合のデータクエリ

メジャメントをまたいだデータクエリ

タイムスタンプの順序

タグ値が空のデータの選択

データ書き込み

書き込みジッターが定期的に発生するのはなぜですか？

ラインプロトコル書き込みの注意事項

書き込み後にデータが表示されないのはなぜですか？

ディスク領域がいっぱいになった後、空き容量を確保しても書き込みが再開されないのはなぜですか？

整数のフィールド値を書き込むにはどうすればよいですか？

TSDB for InfluxDB® は重複するデータポイントをどのように処理しますか？

HTTP API で必要な改行文字

TSDB for InfluxDB® へのデータ書き込み時に避けるべき単語と文字

データ書き込みにおける単一引用符と二重引用符の使い分け

タイムスタンプの精度の重要性

コマンドラインインターフェイス (Influx CLI)

コマンドラインインターフェイスを使用して TSDB for InfluxDB® に接続できないのはなぜですか？

TSDB for InfluxDB® の Influx CLI で、人間が判読できるタイムスタンプを返す方法

非管理者ユーザーが USE を使用してデータベースを指定する方法

TSDB for InfluxDB® の Influx CLI を使用して、デフォルト以外の保存ポリシーにデータを書き込む方法

データ型

ブール値のフィールド値をクエリできない理由

TSDB for InfluxDB® におけるシャード間のフィールド型の不一致の処理

TSDB for InfluxDB® が保存できる整数の最小値と最大値

TSDB for InfluxDB® が保存できるタイムスタンプの最小値と最大値

フィールドに保存されているデータ型を確認する方法

フィールドのデータ型の変更

InfluxQL 関数

関数内で数学演算を実行する方法

クエリでタイムスタンプとしてエポック 0 が返される理由

ネストをサポートする InfluxQL 関数

InfluxDB のデータ移行

セルフマネージド InfluxDB のクラウドへの移行

クラウド上の異なる InfluxDB インスタンス間でのデータ移行

InfluxDB から LindormTSDB へのデータ移行

アクセス時に `IP ブロック` エラーが表示されるのはなぜですか。

`GROUP BY time()` クエリで返される時間間隔の決定要因

`GROUP BY time()` クエリで `now()` より後に発生するタイムスタンプが返されない理由

新しい `DEFAULT` リテンションポリシーを作成した後にデータが失われる理由

`WHERE`句で時間範囲にORを使用すると結果が空になる理由

`fill(previous)` で結果が空になる理由

`INTO` クエリでデータが失われる理由

非管理者ユーザーが `USE` を使用してデータベースを指定する方法