Formateur SQL ClickHouse
Collez une requête ClickHouse et obtenez-la formatée instantanément. Ce formateur utilise une véritable grammaire ClickHouse plutôt qu'une approximation via MySQL, si bien que la syntaxe propre à ClickHouse reste intacte — et il lit les paramètres de requête {name:Type}, ce qui vous permet de les remplir et de récupérer une requête exécutable.
Une requête ClickHouse, avant et après
La requête non formatée ci-dessous est l'exemple chargé dans l'éditeur plus haut, et la sortie est exactement ce que ce formateur en renvoie avec les options par défaut. Rien n'a été retouché à la main.
WITH matched AS (SELECT fingerprint FROM traces_resource WHERE simpleJSONExtractString(labels, 'service.name') = {service:String}), ranked AS (SELECT resource_string_service$$name AS svc, toStartOfInterval(timestamp, INTERVAL 60 SECOND) AS ts, attributes_string['http.method'] AS method, quantile(0.95)(duration_nano) AS p95 FROM signoz_index_v3 PREWHERE timestamp >= {start_ts:UInt64} AND timestamp <= {end_ts:UInt64} WHERE resource_fingerprint GLOBAL IN (SELECT fingerprint FROM matched) GROUP BY svc, ts, method) SELECT * FROM ranked WHERE p95 > {threshold:UInt64} ORDER BY ts DESC SETTINGS max_threads = 8WITH
matched AS (
SELECT
fingerprint
FROM
traces_resource
WHERE
simpleJSONExtractString(labels, 'service.name') = {service:String}
),
ranked AS (
SELECT
resource_string_service$$name AS svc,
toStartOfInterval(timestamp, INTERVAL 60 SECOND) AS ts,
attributes_string['http.method'] AS method,
quantile(0.95)(duration_nano) AS p95
FROM
signoz_index_v3
PREWHERE
timestamp >= {start_ts:UInt64}
AND timestamp <= {end_ts:UInt64}
WHERE
resource_fingerprint GLOBAL IN (
SELECT
fingerprint
FROM
matched
)
GROUP BY
svc,
ts,
method
)
SELECT
*
FROM
ranked
WHERE
p95 > {threshold:UInt64}
ORDER BY
ts DESC
SETTINGS
max_threads = 8La syntaxe ClickHouse qu'il gère
Un formateur générique massacre la syntaxe propre au dialecte ou la refuse tout net. Voici les constructions ClickHouse contre lesquelles ce formateur est testé.
{name:Type} Les paramètres de requête ClickHouse sont détectés comme de vrais paramètres, nommés d'après le paramètre et non son type. Remplissez start_ts une fois et chaque usage se met à jour ; les types DateTime64, Array et Nullable sont associés au bon champ de saisie.
PREWHERE Découvert comme clause de filtre modifiable à part entière, à côté de WHERE, pour que vous puissiez ajuster la clause qui pilote réellement le chemin de lecture de ClickHouse.
ARRAY JOIN Conservé comme une seule clause au lieu d'être scindé en un JOIN fantôme.
attributes['key'] Les indices de map et de tableau sont préservés à l'identique, y compris les clés avec des points comme attributes_string['http.method'].
quantile(0.95)(x) Les fonctions d'agrégation paramétriques gardent leurs deux listes d'arguments collées.
column$$name Les colonnes matérialisées contenant $$ sont traitées comme des identifiants, pas comme une chaîne entre dollars non terminée.
GLOBAL IN Les opérateurs de requête distribuée sont laissés tels quels, et la sous-requête qu'ils contiennent reste modifiable.
SETTINGS / FORMAT Les clauses finales sont reconnues comme des frontières de clause, si bien que modifier un WHERE ne les avale jamais.
FAQ du formateur ClickHouse
Comprend-il les paramètres de requête ClickHouse ?
Oui. Les paramètres {name:Type} de ClickHouse sont détectés, regroupés par nom et typés d'après leur type déclaré. Deux paramètres partageant un type — par exemple {start_ts:UInt64} et {end_ts:UInt64} — restent séparés, et remplir l'un n'écrase pas l'autre. Basculez la sortie en SQL rempli et vous obtenez une requête exécutable directement.
Peut-il formater une requête construite à partir de plusieurs CTE ?
Oui, et il peut les modifier. Chaque clause WHERE et PREWHERE de la requête est listée par la CTE à laquelle elle appartient : choisissez-en une et modifiez-la sous forme d'arbre AND/OR ou de graphe de nœuds. Les modifications sont insérées exactement dans cette clause et rien d'autre ne bouge dans la requête.
Ma requête ClickHouse est-elle envoyée à un serveur ?
Non. Le formatage s'exécute entièrement dans votre navigateur : les requêtes de production, les noms de tables et les valeurs intégrées ne quittent jamais votre machine.
Pourquoi modifier une clause WHERE n'avale-t-il pas le SETTINGS final ?
Parce que SETTINGS et FORMAT sont reconnus à la syntaxe de leurs arguments, et non au simple mot-clé. Cette distinction joue dans les deux sens : une requête qui filtre sur une colonne littéralement nommée settings continue d'être analysée correctement, et un SETTINGS max_threads = 8 final est reconnu comme une limite de clause au lieu d'être aspiré dans la condition en cours d'édition.
ARRAY JOIN et les colonnes de type map sont-ils gérés ?
Oui. ARRAY JOIN reste une clause unique au lieu d'être scindé en un JOIN fantôme, et les indices de map conservent leur texte exact — y compris les clés à points comme attributes_string['http.method'], que des formateurs plus simples cassent en insérant des espaces autour du point.
Gère-t-il les noms de colonnes matérialisées contenant un double signe dollar ?
Oui. Un nom comme resource_string_service$$name est traité comme un identifiant, et non comme l'ouverture d'une chaîne entre dollars à la mode Postgres. Se tromper là-dessus efface le reste de la requête : tous les paramètres et clauses WHERE qui suivent disparaissent sans un mot — exactement la panne rencontrée en collant des schémas SigNoz ou d'observabilité dans un formateur générique.