Réponse
query_log de la base de données system consigne toutes vos requêtes, notamment :
- la quantité de mémoire consommée par la requête, et
- le temps CPU requis
initial_query_id représente l’ID de la requête initiale dans le cadre d’une exécution d’une requête distribuée lancée depuis le nœud qui reçoit la requête. query_id contient l’ID de la requête enfant exécutée sur un autre nœud. Consultez cet article pour plus de détails.youtube (voir le jeu de données YouTube dislikes) :
initial_query_id VS query_id
initial_query_id représente l’ID de la requête initiale pour l’exécution d’une requête distribuée lancée depuis le nœud qui reçoit la requête ;
le champ query_id contient alors l’ID de la requête enfant exécutée sur un autre nœud.
L’exécution distribuée n’est pas la seule cause de valeurs
query_id différentesUne même requête peut aussi engendrer des sous-requêtes internes, journalisées avec leur propre query_id et is_initial_query = 0 — le plus souvent, les requêtes internes que ClickHouse exécute pour évaluer les views. Ces identifiants internes sont attribués par ClickHouse et peuvent ne pas suivre le même format que celui renvoyé à votre client ; pour les étapes liées aux views, vous pouvez voir des valeurs query_id contenant un libellé tel que queryView.... Si vous voulez retrouver exactement la requête telle que vous l’avez envoyée, filtrez sur is_initial_query = 1 (ou query_id = initial_query_id). Il s’agit d’un comportement côté serveur de query_log, identique quel que soit le client utilisé, y compris le SQL Console de Cloud.query_id à la requête ci-dessus, nous recentrons notre recherche sur initial_query_id = a7262fa2-bd8b-4b51-a359-621ccf282417 et hostname() :
query_id != initial_query_id à la clause WHERE :
query_id = initial_query_id ne renverra que les requêtes exécutées sur le nœud local à partir duquel la requête distribuée a été initialement lancée :