Tous les produits
Search
Centre de documentation

Time Series Database:Référence InfluxQL

Dernière mise à jour :Aug 10, 2026

InfluxQL (Influx Query Language) est un langage de requête semblable au SQL pour TSDB for InfluxDB. Cette référence couvre la spécification syntaxique complète, y compris la notation, les littéraux, les instructions, les clauses, les expressions et le fonctionnement interne du moteur de requêtes.

Dans cette rubrique

Notation

La syntaxe InfluxQL est spécifiée à l'aide de la forme Backus-Naur étendue (EBNF), la même notation que celle utilisée dans la spécification du langage de programmation Go.

Production  = production_name "=" [ Expression ] "." .
Expression  = Alternative { "|" Alternative } .
Alternative = Term { Term } .
Term        = production_name | token [ "…" token ] | Group | Option | Repetition .
Group       = "(" Expression ")" .
Option      = "[" Expression "]" .
Repetition  = "{" Expression "}" .

Opérateurs de notation par ordre de priorité croissante :

|   alternation
()  grouping
[]  option (0 or 1 times)
{}  repetition (0 to n times)

Éléments de requête

Caractères

InfluxQL prend en charge le texte Unicode encodé en UTF-8.

newline      = /* the Unicode code point U+000A */ .
unicode_char = /* an arbitrary Unicode code point except newline */ .

Lettres et chiffres

Les lettres InfluxQL incluent les caractères ASCII et les traits de soulignement. Les traits de soulignement (U+005F) se comportent comme des lettres. InfluxQL ne prend en charge que les chiffres décimaux.

letter       = ascii_letter | "_" .
ascii_letter = "A" … "Z" | "a" … "z" .
digit        = "0" … "9" .

Identificateurs

Les identificateurs nomment les bases de données, les politiques de rétention, les utilisateurs, les mesures, les clés de tag et les clés de champ.

Les identificateurs entre guillemets doubles peuvent :

  • Contenir des caractères Unicode (mais pas de sauts de ligne)

  • Utiliser \" pour échapper les guillemets doubles

  • Contenir des mots clés InfluxQL

Les identificateurs sans guillemets doivent :

  • Commencer par une lettre ASCII ou un trait de soulignement

  • Contenir uniquement des lettres ASCII, des chiffres et des traits de soulignement

identifier          = unquoted_identifier | quoted_identifier .
unquoted_identifier = ( letter ) { letter | digit } .
quoted_identifier   = `"` unicode_char { unicode_char } `"` .

Exemples :

cpu
_cpu_stats
"1h"
"anything really"
"1_Crazy-1337.identifier>NAME"

Mots clés

ALL           ALTER         ANY           AS            ASC           BEGIN
BY            CREATE        CONTINUOUS    DATABASE      DATABASES     DEFAULT
DELETE        DESC          DESTINATIONS  DIAGNOSTICS   DISTINCT      DROP
DURATION      END           EVERY         EXPLAIN       FIELD         FOR
FROM          GRANT         GRANTS        GROUP         GROUPS        IN
INF           INSERT        INTO          KEY           KEYS          KILL
LIMIT         SHOW          MEASUREMENT   MEASUREMENTS  NAME          OFFSET
ON            ORDER         PASSWORD      POLICY        POLICIES      PRIVILEGES
QUERIES       QUERY         READ          REPLICATION   RESAMPLE      RETENTION
REVOKE        SELECT        SERIES        SET           SHARD         SHARDS
SLIMIT        SOFFSET       STATS         SUBSCRIPTION  SUBSCRIPTIONS TAG
TO            USER          USERS         VALUES        WHERE         WITH
WRITE

Lorsqu'ils sont utilisés comme identificateurs dans les instructions de requête, les mots clés doivent être entourés de guillemets doubles.

Exception : time

Le mot clé time peut être utilisé comme identificateur sans guillemets doubles dans les noms suivants : requête continue, base de données, mesure, politique de rétention, abonnement et utilisateur. Cependant, time ne peut pas être utilisé comme clé de champ ou clé de tag ; toute tentative d'écriture de données avec time comme clé de champ ou clé de tag renvoie une erreur.

Littéraux

Entiers

InfluxQL ne prend en charge que les entiers décimaux. Les entiers hexadécimaux et octaux ne sont pas pris en charge.

int_lit = ( "1" … "9" ) { digit } .

Nombres à virgule flottante

InfluxQL prend en charge les nombres à virgule flottante, mais pas les exposants.

float_lit = int_lit "." int_lit .

Chaînes

Les chaînes doivent être entourées de guillemets simples. Utilisez \' pour échapper les guillemets simples au sein d'une chaîne.

string_lit = `'` { unicode_char } `'` .

Durées

Un littéral de durée se compose d'un entier suivi immédiatement d'une unité de temps, sans espace entre eux. Plusieurs unités peuvent être combinées pour exprimer une durée.

duration_lit  = int_lit duration_unit .
duration_unit = "ns" | "u" | "µ" | "ms" | "s" | "m" | "h" | "d" | "w" .

Unités valides

Unité Description
ns Nanoseconde (un milliardième de seconde)
u ou µ Microseconde (un millionième de seconde)
ms Milliseconde (un millième de seconde)
s Seconde
m Minute
h Heure
d Jour
w Semaine

Date et heure

La date et l'heure dans InfluxQL suivent les règles de formatage et d'analyse de Go plutôt que l'EBNF. L'horodatage de référence — 2 janvier 2006, 15:04:05 — définit le format requis :

time_lit = "2006-01-02 15:04:05.999999" | "2006-01-02" .

Valeurs booléennes

bool_lit = TRUE | FALSE .

Expressions régulières

regex_lit = "/" { unicode_char } "/" .

Opérateurs : =~ correspond, !~ ne correspond pas.

Les expressions régulières peuvent être utilisées pour :

  • Les clés de champ et les clés de tag dans les clauses SELECT

  • Les mesures dans les clauses FROM

  • Les valeurs de tag dans les clauses WHERE

  • Les clés de tag dans les clauses GROUP BY

Les expressions régulières ne peuvent pas être utilisées pour :

  • Les valeurs de champ non textuelles dans les clauses WHERE

  • Les bases de données

  • Les politiques de rétention

Requêtes

Une requête se compose d'une ou plusieurs instructions séparées par des points-virgules (;).

query     = statement { ";" statement } .

statement = alter_retention_policy_stmt |
            create_continuous_query_stmt |
            create_database_stmt |
            create_retention_policy_stmt |
            create_subscription_stmt |
            create_user_stmt |
            delete_stmt |
            drop_continuous_query_stmt |
            drop_database_stmt |
            drop_measurement_stmt |
            drop_retention_policy_stmt |
            drop_series_stmt |
            drop_shard_stmt |
            drop_subscription_stmt |
            drop_user_stmt |
            explain_stmt |
            explain_analyze_stmt |
            grant_stmt |
            kill_query_statement |
            revoke_stmt |
            select_stmt |
            show_continuous_queries_stmt |
            show_databases_stmt |
            show_diagnostics_stmt |
            show_field_key_cardinality_stmt |
            show_field_keys_stmt |
            show_grants_stmt |
            show_measurement_cardinality_stmt |
            show_measurement_exact_cardinality_stmt |
            show_measurements_stmt |
            show_queries_stmt |
            show_retention_policies_stmt |
            show_series_cardinality_stmt |
            show_series_exact_cardinality_stmt |
            show_series_stmt |
            show_shard_groups_stmt |
            show_shards_stmt |
            show_stats_stmt |
            show_subscriptions_stmt |
            show_tag_key_cardinality_stmt |
            show_tag_key_exact_cardinality_stmt |
            show_tag_keys_stmt |
            show_tag_values_stmt |
            show_tag_values_cardinality_stmt |
            show_users_stmt .

Instructions

DELETE

Important

TSDB for InfluxDB® prend en charge les opérations de suppression. En raison de la syntaxe de suppression sous-jacente dans InfluxDB®, les opérations de suppression peuvent provoquer des interblocages et entraîner des échecs de lecture/écriture. Évitez d'effectuer des opérations de suppression dans TSDB for InfluxDB®.

delete_stmt = "DELETE" ( from_clause | where_clause | from_clause where_clause ) .

Exemples :

DELETE FROM "cpu"
DELETE FROM "cpu" WHERE time < '2000-01-01T00:00:00Z'
DELETE WHERE time < '2000-01-01T00:00:00Z'

EXPLAIN

EXPLAIN analyse et planifie une requête, puis renvoie un résumé estimé du coût des ressources.

Contrairement aux moteurs SQL qui prennent en charge les opérations de jointure, InfluxQL ne prend pas en charge les jointures. La sortie du plan reflète les coûts spécifiques aux requêtes InfluxQL : le nombre de séries temporelles accessibles, le nombre d'itérateurs lisant les fichiers Time-Structured Merge Tree (TSM) et le nombre de blocs TSM analysés.

Un résultat EXPLAIN comprend :

  • Expression

  • Champs auxiliaires

  • Nombre de shards

  • Nombre de séries

  • Valeurs mises en cache

  • Nombre de fichiers

  • Nombre de blocs

  • Taille des blocs

Exemple :

> EXPLAIN SELECT sum(pointReq) FROM "_internal"."monitor"."write" GROUP BY hostname;
QUERY PLAN
----------
EXPRESSION: sum(pointReq::integer)
NUMBER OF SHARDS: 2
NUMBER OF SERIES: 2
CACHED VALUES: 110
NUMBER OF FILES: 1
NUMBER OF BLOCKS: 1
SIZE OF BLOCKS: 931

EXPLAIN ANALYZE

EXPLAIN ANALYZE exécute une requête InfluxQL et renvoie les coûts réels des ressources mesurés pendant l'exécution.

explain_analyze_stmt = "EXPLAIN ANALYZE" select_stmt .

Exemple :

> EXPLAIN ANALYZE SELECT sum(pointReq) FROM "_internal"."monitor"."write" GROUP BY hostname;
EXPLAIN ANALYZE
---------------
.
└── select
    ├── execution_time: 242.167µs
    ├── planning_time: 2.165637ms
    ├── total_time: 2.407804ms
    └── field_iterators
        ├── labels
        │   └── statement: SELECT sum(pointReq::integer) FROM "_internal"."monitor"."write" GROUP BY hostname
        └── expression
            ├── labels
            │   └── expr: sum(pointReq::integer)
            ├── create_iterator
            │   ├── labels
            │   │   ├── measurement: write
            │   │   └── shard_id: 57
            │   ├── cursors_ref: 1
            │   ├── cursors_aux: 0
            │   ├── cursors_cond: 0
            │   ├── float_blocks_decoded: 0
            │   ├── float_blocks_size_bytes: 0
            │   ├── integer_blocks_decoded: 1
            │   ├── integer_blocks_size_bytes: 931
            │   ├── unsigned_blocks_decoded: 0
            │   ├── unsigned_blocks_size_bytes: 0
            │   ├── string_blocks_decoded: 0
            │   ├── string_blocks_size_bytes: 0
            │   ├── boolean_blocks_decoded: 0
            │   ├── boolean_blocks_size_bytes: 0
            │   └── planning_time: 1.401099ms
            └── create_iterator
                ├── labels
                │   ├── measurement: write
                │   └── shard_id: 58
                ├── cursors_ref: 1
                ├── cursors_aux: 0
                ├── cursors_cond: 0
                ├── float_blocks_decoded: 0
                ├── float_blocks_size_bytes: 0
                ├── integer_blocks_decoded: 0
                ├── integer_blocks_size_bytes: 0
                ├── unsigned_blocks_decoded: 0
                ├── unsigned_blocks_size_bytes: 0
                ├── string_blocks_decoded: 0
                ├── string_blocks_size_bytes: 0
                ├── boolean_blocks_decoded: 0
                ├── boolean_blocks_size_bytes: 0
                └── planning_time: 76.192µs

KILL QUERY

KILL QUERY arrête une requête en cours d'exécution grâce à son ID de requête.

kill_query_statement = "KILL QUERY" query_id .

Pour trouver l'ID de requête, exécutez SHOW QUERIES. Le champ qid dans le résultat correspond à l'ID de requête.

Exemple :

-- Kill the query with qid 36
KILL QUERY 36

SELECT

select_stmt = "SELECT" fields from_clause [ into_clause ] [ where_clause ]
              [ group_by_clause ] [ order_by_clause ] [ limit_clause ]
              [ offset_clause ] [ slimit_clause ] [ soffset_clause ] [ timezone_clause ] .

Exemples :

Interrogez les données de toutes les mesures dont le préfixe est cpu, et écrivez les résultats dans les mêmes noms de mesure dans la politique de rétention cpu_1h :

SELECT mean("value") INTO "cpu_1h".:MEASUREMENT FROM /cpu.*/

Interrogez les données de la mesure cpu, regroupées par jour dans le fuseau horaire America/Chicago :

SELECT mean("value") FROM "cpu" GROUP BY region, time(1d) fill(0) tz('America/Chicago')

SHOW CARDINALITY

SHOW CARDINALITY est une famille de commandes permettant d'interroger la cardinalité des mesures, des séries, des clés de tag, des valeurs de tag et des clés de champ.

Deux modes sont disponibles :

  • Cardinalité estimée : calculée à partir d'un plan interne. Faible surcharge quelle que soit la taille des données. Utilisez ce mode par défaut.

  • Cardinalité exacte : calculée à partir des données TSM. Surcharge élevée pour les grands ensembles de données. Utilisez ce mode uniquement lorsque votre cas d'utilisation exige une précision absolue.

Le filtrage basé sur le temps est disponible uniquement lorsque la fonctionnalité Time Series Index (TSI) est activée pour votre base de données.

Pour la syntaxe de chaque instruction individuelle, consultez :

SHOW CONTINUOUS QUERIES

show_continuous_queries_stmt = "SHOW CONTINUOUS QUERIES" .

Exemple :

-- List all continuous queries
SHOW CONTINUOUS QUERIES

SHOW DATABASES

show_databases_stmt = "SHOW DATABASES" .

Exemple :

-- List all databases
SHOW DATABASES

SHOW DIAGNOSTICS

Renvoie les informations sur le nœud, y compris les informations de build, les détails d'exécution, le nom d'hôte, la configuration du serveur, l'utilisation de la mémoire et les diagnostics d'exécution Go.

show_diagnostics_stmt = "SHOW DIAGNOSTICS" .

SHOW FIELD KEY CARDINALITY

Renvoie la cardinalité estimée ou exacte de l'ensemble des clés de champ. Sans clause ON, la base de données actuelle est utilisée.

L'utilisation de clauses facultatives renvoie la cardinalité exacte. Le filtrage temporel nécessite TSI ; le filtre time ne peut pas être utilisé dans les clauses WHERE.

show_field_key_cardinality_stmt =
    "SHOW FIELD KEY CARDINALITY"
    [ on_clause ] [ from_clause ] [ where_clause ] [ group_by_clause ] [ limit_clause ] [ offset_clause ]

show_field_key_exact_cardinality_stmt =
    "SHOW FIELD KEY EXACT CARDINALITY"
    [ on_clause ] [ from_clause ] [ where_clause ] [ group_by_clause ] [ limit_clause ] [ offset_clause ]

Exemples :

-- Estimated cardinality for the current database
SHOW FIELD KEY CARDINALITY

-- Exact cardinality for a specified database
SHOW FIELD KEY EXACT CARDINALITY ON mydb

SHOW FIELD KEYS

show_field_keys_stmt = "SHOW FIELD KEYS" [ on_clause ] [ from_clause ] .

Exemples :

-- Show field keys and value types from all measurements
SHOW FIELD KEYS

-- Show field keys and value types from a specific measurement
SHOW FIELD KEYS FROM "cpu"

SHOW GRANTS

show_grants_stmt = "SHOW GRANTS FOR" user_name .

Exemple :

-- Show grants for jdoe
SHOW GRANTS FOR "jdoe"

SHOW MEASUREMENT CARDINALITY

Renvoie la cardinalité estimée ou exacte de l'ensemble des mesures. Sans clause ON, la base de données actuelle est utilisée.

L'utilisation de clauses facultatives renvoie la cardinalité exacte. Le filtrage temporel nécessite TSI ; le filtre time ne peut pas être utilisé dans les clauses WHERE.

show_measurement_cardinality_stmt =
    "SHOW MEASUREMENT CARDINALITY"
    [ on_clause ] [ from_clause ] [ where_clause ] [ group_by_clause ] [ limit_clause ] [ offset_clause ]

show_measurement_exact_cardinality_stmt =
    "SHOW MEASUREMENT EXACT CARDINALITY"
    [ on_clause ] [ from_clause ] [ where_clause ] [ group_by_clause ] [ limit_clause ] [ offset_clause ]

Exemples :

-- Estimated cardinality for the current database
SHOW MEASUREMENT CARDINALITY

-- Exact cardinality for a specified database
SHOW MEASUREMENT EXACT CARDINALITY ON mydb

SHOW MEASUREMENTS

show_measurements_stmt = "SHOW MEASUREMENTS" [ on_clause ] [ with_measurement_clause ] [ where_clause ] [ limit_clause ] [ offset_clause ] .

Exemples :

-- List all measurements
SHOW MEASUREMENTS

-- Measurements where region = 'uswest' and host = 'serverA'
SHOW MEASUREMENTS WHERE "region" = 'uswest' AND "host" = 'serverA'

-- Measurements starting with 'h2o'
SHOW MEASUREMENTS WITH MEASUREMENT =~ /h2o.*/

SHOW QUERIES

show_queries_stmt = "SHOW QUERIES" .

Exemple :

-- List all currently running queries
SHOW QUERIES

SHOW RETENTION POLICIES

show_retention_policies_stmt = "SHOW RETENTION POLICIES" [ on_clause ] .

Exemple :

-- List all retention policies for a database
SHOW RETENTION POLICIES ON "mydb"

SHOW SERIES

show_series_stmt = "SHOW SERIES" [ on_clause ] [ from_clause ] [ where_clause ] [ limit_clause ] [ offset_clause ] .

Exemple :

SHOW SERIES FROM "telegraf"."autogen"."cpu" WHERE cpu = 'cpu8'

SHOW SERIES CARDINALITY

Renvoie la cardinalité estimée ou exacte de l'ensemble des séries. Sans clause ON, la base de données actuelle est utilisée.

La cardinalité des séries affecte directement l'utilisation de la RAM.

L'utilisation de clauses facultatives renvoie la cardinalité exacte. Le filtrage temporel nécessite TSI ; le filtre time ne peut pas être utilisé dans les clauses WHERE.

show_series_cardinality_stmt =
    "SHOW SERIES CARDINALITY"
    [ on_clause ] [ from_clause ] [ where_clause ] [ group_by_clause ] [ limit_clause ] [ offset_clause ]

show_series_exact_cardinality_stmt =
    "SHOW SERIES EXACT CARDINALITY"
    [ on_clause ] [ from_clause ] [ where_clause ] [ group_by_clause ] [ limit_clause ] [ offset_clause ]

Exemples :

-- Estimated cardinality for the current database
SHOW SERIES CARDINALITY

-- Estimated cardinality for a specified database
SHOW SERIES CARDINALITY ON mydb

-- Exact cardinality for the current database
SHOW SERIES EXACT CARDINALITY

-- Exact cardinality for a specified database
SHOW SERIES EXACT CARDINALITY ON mydb

SHOW SHARD GROUPS

show_shard_groups_stmt = "SHOW SHARD GROUPS" .

Exemple :

SHOW SHARD GROUPS

SHOW SHARDS

show_shards_stmt = "SHOW SHARDS" .

Exemple :

SHOW SHARDS

SHOW STATS

Renvoie des informations statistiques sur un nœud TSDB for InfluxDB et ses composants disponibles.

show_stats_stmt = "SHOW STATS [ FOR '<component>' | 'indexes' ]"

SHOW STATS

Renvoie les statistiques pour tous les composants, à l'exception de l'utilisation de la mémoire d'index. Les valeurs statistiques sont stockées en mémoire et réinitialisées à zéro lors du redémarrage du nœud. TSDB for InfluxDB exécute automatiquement SHOW STATS toutes les 10 secondes pour remplir la base de données _internal.

SHOW STATS FOR \<component\>

Renvoie les statistiques pour un composant spécifique. Pour le composant runtime, renvoie un résumé de l'utilisation de la mémoire basé sur le package d'exécution Go.

SHOW STATS FOR 'indexes'

Renvoie l'utilisation estimée de la mémoire pour tous les index. Ces informations sont exclues de SHOW STATS car leur calcul consomme beaucoup de ressources.

Exemple :

> SHOW STATS
name: runtime
-------------
Alloc   Frees   HeapAlloc  HeapIdle   HeapInUse  HeapObjects  HeapReleased  HeapSys   Lookups  Mallocs  NumGC  NumGoroutine  PauseTotalNs  Sys        TotalAlloc
4136056 6684537 4136056    34586624   5816320    49412        0             40402944  110      6733949  83     44            36083006      46692600   439945704

name: graphite
tags: proto=tcp
batches_tx  bytes_rx  connections_active  connections_handled  points_rx  points_tx
----------  --------  ------------------  -------------------  ---------  ---------
159         3999750   0                   1                    158110     158110

SHOW SUBSCRIPTIONS

show_subscriptions_stmt = "SHOW SUBSCRIPTIONS" .

Exemple :

SHOW SUBSCRIPTIONS

SHOW TAG KEY CARDINALITY

Renvoie la cardinalité estimée ou exacte de l'ensemble des clés de tag. Sans clause ON, la base de données actuelle est utilisée.

L'utilisation de clauses facultatives renvoie la cardinalité exacte. Le filtrage temporel nécessite TSI ; le filtre time ne peut pas être utilisé dans les clauses WHERE.

show_tag_key_cardinality_stmt =
    "SHOW TAG KEY CARDINALITY"
    [ on_clause ] [ from_clause ] [ where_clause ] [ group_by_clause ] [ limit_clause ] [ offset_clause ]

show_tag_key_exact_cardinality_stmt =
    "SHOW TAG KEY EXACT CARDINALITY"
    [ on_clause ] [ from_clause ] [ where_clause ] [ group_by_clause ] [ limit_clause ] [ offset_clause ]

Exemples :

-- Estimated tag key cardinality
SHOW TAG KEY CARDINALITY

-- Exact tag key cardinality
SHOW TAG KEY EXACT CARDINALITY

SHOW TAG KEYS

show_tag_keys_stmt = "SHOW TAG KEYS" [ on_clause ] [ from_clause ] [ where_clause ]
                     [ limit_clause ] [ offset_clause ] .

Exemples :

-- List all tag keys
SHOW TAG KEYS

-- Tag keys from the cpu measurement
SHOW TAG KEYS FROM "cpu"

-- Tag keys from cpu where region = 'uswest'
SHOW TAG KEYS FROM "cpu" WHERE "region" = 'uswest'

-- Tag keys where host = 'serverA'
SHOW TAG KEYS WHERE "host" = 'serverA'

SHOW TAG VALUES

show_tag_values_stmt = "SHOW TAG VALUES" [ on_clause ] [ from_clause ] with_tag_clause [ where_clause ]
                       [ limit_clause ] [ offset_clause ] .

Exemples :

-- All tag values for the region tag across all measurements
SHOW TAG VALUES WITH KEY = "region"

-- Tag values for the region tag from the cpu measurement
SHOW TAG VALUES FROM "cpu" WITH KEY = "region"

-- Tag values for all tag keys that don't contain the letter 'c'
SHOW TAG VALUES WITH KEY !~ /.*c.*/

-- Tag values for region and host from cpu where service = 'redis'
SHOW TAG VALUES FROM "cpu" WITH KEY IN ("region", "host") WHERE "service" = 'redis'

SHOW TAG VALUES CARDINALITY

Renvoie la cardinalité estimée ou exacte des valeurs de tag pour les clés de tag spécifiées. Sans clause ON, la base de données actuelle est utilisée.

L'utilisation de clauses facultatives renvoie la cardinalité exacte. Le filtrage temporel nécessite TSI.

show_tag_values_cardinality_stmt =
    "SHOW TAG VALUES CARDINALITY"
    [ on_clause ] [ from_clause ] [ where_clause ] [ group_by_clause ] [ limit_clause ] [ offset_clause ] with_key_clause

show_tag_values_exact_cardinality_stmt =
    "SHOW TAG VALUES EXACT CARDINALITY"
    [ on_clause ] [ from_clause ] [ where_clause ] [ group_by_clause ] [ limit_clause ] [ offset_clause ] with_key_clause

Exemples :

-- Estimated cardinality for a tag key
SHOW TAG VALUES CARDINALITY WITH KEY = "myTagKey"

-- Exact cardinality for a tag key
SHOW TAG VALUES EXACT CARDINALITY WITH KEY = "myTagKey"

SHOW USERS

show_users_stmt = "SHOW USERS" .

Exemple :

-- List all users
SHOW USERS

Clauses

from_clause     = "FROM" measurements .

group_by_clause = "GROUP BY" dimensions fill(fill_option) .

into_clause     = "INTO" ( measurement | back_ref ) .

limit_clause    = "LIMIT" int_lit .

offset_clause   = "OFFSET" int_lit .

slimit_clause   = "SLIMIT" int_lit .

soffset_clause  = "SOFFSET" int_lit .

timezone_clause = tz(string_lit) .

on_clause       = "ON" db_name .

order_by_clause = "ORDER BY" sort_fields .

to_clause       = "TO" user_name .

where_clause    = "WHERE" expr .

with_measurement_clause = "WITH MEASUREMENT" ( "=" measurement | "=~" regex_lit ) .

with_tag_clause = "WITH KEY" ( "=" tag_key | "!=" tag_key | "=~" regex_lit | "IN (" tag_keys ")" ) .

Expressions

binary_op  = "+" | "-" | "*" | "/" | "%" | "&" | "|" | "^" | "AND" |
             "OR" | "=" | "!=" | "<>" | "<" | "<=" | ">" | ">=" .

expr       = unary_expr { binary_op unary_expr } .

unary_expr = "(" expr ")" | var_ref | time_lit | string_lit | int_lit |
             float_lit | bool_lit | duration_lit | regex_lit .

Autres éléments grammaticaux

alias            = "AS" identifier .

back_ref         = ( policy_name ".:MEASUREMENT" ) |
                   ( db_name "." [ policy_name ] ".:MEASUREMENT" ) .

db_name          = identifier .

dimension        = expr .

dimensions       = dimension { "," dimension } .

field_key        = identifier .

field            = expr [ alias ] .

fields           = field { "," field } .

fill_option      = "null" | "none" | "previous" | int_lit | float_lit | "linear" .

host             = string_lit .

measurement      = measurement_name |
                   ( policy_name "." measurement_name ) |
                   ( db_name "." [ policy_name ] "." measurement_name ) .

measurements     = measurement { "," measurement } .

measurement_name = identifier | regex_lit .

password         = string_lit .

policy_name      = identifier .

privilege        = "ALL" [ "PRIVILEGES" ] | "READ" | "WRITE" .

query_id         = int_lit .

query_name       = identifier .

retention_policy = identifier .

retention_policy_option      = retention_policy_duration |
                               retention_policy_replication |
                               retention_policy_shard_group_duration |
                               "DEFAULT" .

retention_policy_duration    = "DURATION" duration_lit .

retention_policy_replication = "REPLICATION" int_lit .

retention_policy_shard_group_duration = "SHARD DURATION" duration_lit .

retention_policy_name = "NAME" identifier .

series_id        = int_lit .

shard_id         = int_lit .

sort_field       = field_key [ ASC | DESC ] .

sort_fields      = sort_field { "," sort_field } .

subscription_name = identifier .

tag_key          = identifier .

tag_keys         = tag_key { "," tag_key } .

user_name        = identifier .

var_ref          = measurement .

Commentaires

Ajoutez des commentaires dans les instructions InfluxQL pour documenter vos requêtes.

  • Commentaire sur une seule ligne : commence par -- et se termine au saut de ligne suivant. Ne peut pas s'étendre sur plusieurs lignes.

  • Commentaire multiligne : commence par /* et se termine par */. Peut s'étendre sur plusieurs lignes. Les commentaires multilignes imbriqués ne sont pas pris en charge.

Fonctionnement interne du moteur de requêtes

Comprendre comment le moteur de requêtes exécute InfluxQL vous aide à rédiger des requêtes efficaces et à interpréter la sortie de EXPLAIN ANALYZE.

Cycle de vie d'une requête

Chaque requête InfluxQL suit quatre étapes :

  1. L'instruction est tokenisée et analysée en un arbre de syntaxe abstraite (AST) — la représentation en mémoire de la requête.

  2. L'AST est transmis à l'exécuteur de requêtes, qui le dirige vers le gestionnaire approprié. Les requêtes de métadonnées vont au service de métadonnées ; les instructions SELECT s'exécutent contre les shards.

  3. Le moteur de requêtes identifie les shards correspondant à la plage de temps dans l'instruction SELECT, puis crée un itérateur pour chaque champ interrogé.

  4. Les itérateurs sont transmis à un émetteur, qui libère les itérateurs, combine les points de données résultants, convertit les points de données simples basés sur le temps en objets complexes et les renvoie au client.

Itérateurs

Les itérateurs constituent l'abstraction centrale du moteur de requêtes. Chaque itérateur fournit une interface simple pour diffuser des points de données. Par exemple, un FloatIterator diffuse des points de données à virgule flottante :

type FloatIterator interface {
    Next() *FloatPoint
}

Les itérateurs sont créés via l'interface IteratorCreator :

type IteratorCreator interface {
    CreateIterator(opt *IteratorOptions) (Iterator, error)
}

IteratorOptions spécifie les champs à lire, la plage de temps et les dimensions de regroupement. IteratorCreator est disponible aux niveaux Shards, Shard et Engine, ce qui permet au moteur de pousser les opérations — par exemple, de pré-agréger les données avant que COUNT() ne renvoie les résultats.

Les itérateurs peuvent être composés : DistinctIterator calcule les valeurs distinctes dans chaque fenêtre de temps à partir d'un itérateur d'entrée ; FillIterator génère des valeurs de remplacement pour les points de données manquants.

Un exemple composé — calcul de la dérivée d'une moyenne :

SELECT DERIVATIVE(MEAN(value), 20m) FROM cpu GROUP BY time(10m)

Cela produit un mean iterator (à partir des shards), enveloppé par un derivative iterator au niveau du moteur.

Champs auxiliaires

Les fonctions sélectrices telles que FIRST(), LAST(), MIN() et MAX() renvoient à la fois le point de données sélectionné et les champs connexes de la même ligne.

Par exemple :

SELECT FIRST(value), host FROM cpu GROUP BY time(1h)

Cela renvoie la value du premier point de données de chaque heure ainsi que l'host associé. En interne, le moteur utilise un seul type de point de données value et attache host en tant que champ auxiliaire — un champ transporté avec la valeur principale jusqu'à ce qu'il atteigne l'émetteur. L'émetteur sépare ensuite les champs auxiliaires et les dirige vers leurs itérateurs respectifs.

Itérateurs intégrés

Le moteur de requêtes fournit les types d'itérateurs intégrés suivants :

Itérateur Objectif
Merge iterator Fusionne un ou plusieurs itérateurs du même type sans tri par temps. Utilisé pour les requêtes d'agrégation nécessitant un accès rapide et ne requérant pas d'ordre.
Sorted merge iterator Fusionne et trie les points de données par temps. Plus lent que les merge iterators. Utilisé pour les requêtes non agrégées renvoyant des données brutes dans l'ordre chronologique.
Limit iterator Limite les points de données par nom ou groupe de tags, en fonction des clauses LIMIT et OFFSET.
Fill iterator Génère des valeurs de remplacement pour les points de données manquants : null, none, la valeur précédente, une valeur numérique spécifiée ou une interpolation linéaire.
Buffered iterator Renvoie les points de données à un état non lu afin qu'ils puissent être relus. Utilisé pour les opérations de consultation anticipée des fenêtres de temps.
Reduce iterator Applique une fonction de réduction à chaque point de données dans une fenêtre de temps, renvoyant tous les résultats après la fermeture de la fenêtre. Utilisé pour les agrégats simples comme COUNT().
Reduce slice iterator Collecte tous les points de données dans une fenêtre de temps, puis transmet la tranche complète à une fonction de réduction. Utilisé pour les agrégats comme DERIVATIVE().
Transform iterator Applique une fonction de transformation à chaque point de données d'entrée pour produire un résultat d'expression binaire.
Dedupe iterator Supprime les doublons de points de données et ne renvoie que les valeurs uniques. Consomme beaucoup de ressources ; convient uniquement aux petits ensembles de données tels que les requêtes de métadonnées.

Itérateurs d'appel

Les fonctions InfluxQL s'exécutent à deux niveaux :

  • Niveau shard : les fonctions comme COUNT() s'exécutent au sein de chaque shard. Un count iterator agrège plusieurs itérateurs de comptage par shard en un total. Ces itérateurs sont créés à l'aide de NewCallIterator().

  • Niveau engine : les fonctions comme DERIVATIVE() nécessitent tous les points de données d'une fenêtre de temps avant de calculer les résultats. Ces itérateurs ne peuvent pas être poussés vers des shards individuels — le moteur de requêtes les construit après avoir collecté la sortie des shards.

InfluxDB® est une marque déposée par InfluxData, qui n'est pas affiliée à TSDB for InfluxDB® et ne l'approuve pas.