system.session_query_ids

Table système contenant les identifiants des requêtes exécutées dans la session en cours.

​

Description

Contient les identifiants des requêtes exécutées dans la session en cours, dans l’ordre d’exécution. Utilisez-la pour retrouver « les requêtes que je viens d’exécuter » dans system.query_log sans avoir à affecter un query_id côté client ni à étiqueter les requêtes avec log_comment.

Le contenu est propre à la session : chaque session ne voit que son propre historique, et les requêtes des autres sessions n’y apparaissent jamais.

Un identifiant de requête est enregistré au démarrage de la requête, par conséquent :

• La requête en cours d’exécution est déjà visible lorsqu’elle interroge la table.
• Les requêtes en échec sont également enregistrées — récupérer l’identifiant d’une requête qui vient d’échouer est l’un des principaux cas d’usage.

Les requêtes internes (flushes des journaux système et opérations similaires) ne sont pas enregistrées. Les sous-requêtes que les requêtes distribuées exécutent sur des shards distants ne le sont pas non plus : seule la requête initiatrice apparaît, dans la session de l’initiator.

​

Portée de la session par interface

• Connexions natives/TCP (clickhouse-client, drivers) et clickhouse-local : la session correspond à la connexion ; l’historique s’accumule donc sur l’ensemble des requêtes de la connexion, y compris lors des appels du client comportant plusieurs requêtes.
• HTTP avec le Paramètre session_id : l’historique est conservé d’une requête à l’autre dès lors qu’elles transmettent le même session_id, jusqu’à l’expiration de la session.
• HTTP sans session_id : chaque requête constitue sa propre session ; la table n’affiche donc jamais que la requête en cours.

​

Taille de l’historique

L’historique est un buffer circulaire dont la taille est limitée par le paramètre de session session_query_ids_history_size (valeur par défaut : 1000) ; lorsque l’historique dépasse cette taille, les entries les plus anciennes sont évincées en premier. La valeur 0 désactive l’enregistrement ; les entries enregistrées auparavant restent dans la table jusqu’à ce qu’elles soient truncated ou évincées.

Ce PARAMÈTRE est lu au démarrage de la requête, avant que celle-ci ne soit parsed : une SETTINGS clause présente dans la requête elle-même n’a donc aucune incidence sur son enregistrement ; utilisez plutôt SET, un HTTP URL Paramètre ou un settings profile.

​

TRUNCATE

TRUNCATE TABLE system.session_query_ids efface l’historique de la session en cours. Le compteur de séquence n’est pas réinitialisé : les valeurs sequence_number ne sont donc jamais réutilisées au sein d’une même session.

​

Colonnes

• sequence_number (UInt64) — Position de la requête au sein de la session, croissante de façon monotone.
• query_id (String) — L’identifiant de la requête ; peut être joint à system.query_log.

​

Exemple

Exécutez quelques requêtes, puis récupérez leurs détails depuis system.query_log :

SELECT 1 FORMAT Null;
SELECT 2 FORMAT Null;

SELECT * FROM system.session_query_ids;

┌─sequence_number─┬─query_id─────────────────────────────┐
│               1 │ 4c9e97a3-b806-4a5c-9a94-5a614c3d0b3f │
│               2 │ 8f9a2f59-30d3-4f8e-b3a1-6a0c1a4d3e2b │
│               3 │ f2b1c4d8-7e6a-4b5c-8d9e-0a1b2c3d4e5f │
└─────────────────┴──────────────────────────────────────┘

La requête en cours est enregistrée dès son démarrage : elle apparaît donc comme la dernière entry. Les timestamps, le status et tous les autres détails sont accessibles en joignant system.query_log :

SYSTEM FLUSH LOGS query_log;

SELECT query_id, type, query, query_duration_ms
FROM system.query_log
WHERE query_id IN (SELECT query_id FROM system.session_query_ids)
ORDER BY event_time_microseconds;

​

Voir aussi

• system.query_log - Détails des requêtes exécutées.
• Paramètre session_query_ids_history_size.