Formatador de SQL para ClickHouse
Cole uma consulta do ClickHouse e receba-a formatada na hora. Este formatador usa uma gramática real do ClickHouse em vez de aproximá-la com MySQL, então a sintaxe exclusiva do ClickHouse sobrevive intacta — e ele lê os parâmetros de consulta {name:Type}, permitindo preenchê-los e obter uma consulta executável de volta.
Uma consulta ClickHouse, antes e depois
A consulta sem formatação abaixo é o exemplo carregado no editor acima, e a saída é exatamente o que este formatador devolve para ela com as opções padrão. Nada foi ajustado à mão.
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 = 8Sintaxe do ClickHouse que ele trata
Um formatador genérico destrói a sintaxe específica do dialeto ou simplesmente a recusa. Estas são as construções do ClickHouse contra as quais este formatador é testado.
{name:Type} Os parâmetros de consulta do ClickHouse são detectados como parâmetros reais, nomeados pelo parâmetro e não pelo tipo. Preencha start_ts uma vez e todos os usos são atualizados; os tipos DateTime64, Array e Nullable mapeiam para o campo adequado.
PREWHERE É descoberta como cláusula de filtro editável própria, ao lado do WHERE, para você ajustar a cláusula que realmente comanda o caminho de leitura do ClickHouse.
ARRAY JOIN Mantida como uma única cláusula em vez de ser quebrada em um JOIN fantasma.
attributes['key'] Subscritos de mapa e array são preservados exatamente, incluindo chaves com pontos como attributes_string['http.method'].
quantile(0.95)(x) Funções de agregação paramétricas mantêm as duas listas de argumentos juntas.
column$$name Colunas materializadas que contêm $$ são tratadas como identificadores, não como uma string entre sinais de dólar não terminada.
GLOBAL IN Operadores de consulta distribuída são mantidos literalmente, e a subconsulta dentro deles continua editável.
SETTINGS / FORMAT Cláusulas finais são reconhecidas como limites de cláusula, então editar um WHERE nunca as engole.
Perguntas frequentes do formatador de ClickHouse
Ele entende os parâmetros de consulta do ClickHouse?
Sim. Os parâmetros {name:Type} do ClickHouse são detectados, agrupados por nome e tipados a partir do tipo declarado. Dois parâmetros que compartilham o tipo — digamos {start_ts:UInt64} e {end_ts:UInt64} — permanecem separados, e preencher um não sobrescreve o outro. Troque a saída para SQL com valores e você recebe uma consulta que pode executar direto.
Ele formata uma consulta montada com várias CTEs?
Sim, e também consegue editá-las. Toda cláusula WHERE e PREWHERE da consulta é listada pela CTE a que pertence, então você escolhe uma e a edita como árvore AND/OR ou grafo de nós. As edições são inseridas exatamente naquela cláusula e nada mais na consulta se move.
Minha consulta do ClickHouse é enviada para um servidor?
Não. A formatação roda inteiramente no seu navegador, então consultas de produção, nomes de tabela e valores embutidos nunca saem da sua máquina.
Por que editar um WHERE não engole o SETTINGS do final?
Porque SETTINGS e FORMAT são reconhecidos pela sintaxe dos seus argumentos, não pela palavra-chave isolada. Essa distinção importa nos dois sentidos: uma consulta que filtra por uma coluna chamada literalmente settings continua sendo analisada corretamente, e um SETTINGS max_threads = 8 no final é reconhecido como limite de cláusula em vez de ser puxado para dentro da condição que você está editando.
ARRAY JOIN e colunas de mapa são tratados?
Sim. ARRAY JOIN continua sendo uma única cláusula em vez de virar um JOIN fantasma, e os índices de mapa mantêm o texto exato — inclusive chaves com ponto como attributes_string['http.method'], que formatadores mais simples quebram ao inserir espaços em volta do ponto.
Ele lida com nomes de colunas materializadas com cifrão duplo?
Sim. Um nome como resource_string_service$$name é tratado como identificador, não como a abertura de uma string entre cifrões no estilo Postgres. Errar isso apaga o restante da consulta, então todos os parâmetros e cláusulas WHERE seguintes somem silenciosamente — exatamente a falha que aparece ao colar esquemas do SigNoz ou de observabilidade em um formatador genérico.