Formatador de SQL
Formate e embeleze SQL para PostgreSQL, MySQL, SQLite e mais.
Sobre esta ferramenta
Cole uma consulta, mesmo uma linha longa tirada de um log, e receba-a organizada com uma cláusula por linha. Escolha o dialeto SQL, a caixa das palavras-chave e a indentação.
Como usar
- Cole uma consulta, por exemplo uma linha longa copiada de um log ou da saída de depuração de um ORM.
- Escolha o dialeto do seu banco de dados para que as palavras-chave e a sintaxe dele sejam reconhecidas.
- Escolha a caixa das palavras-chave (MAIÚSCULAS, minúsculas ou como digitado) e a indentação, ou Uma linha para compactar.
- Copie a consulta formatada.
Perguntas
- Quais bancos de dados são suportados?
- SQL padrão, PostgreSQL, MySQL, MariaDB, SQLite, SQL Server (T-SQL), Oracle PL/SQL, BigQuery, Snowflake, Redshift, DuckDB, ClickHouse, Spark SQL e Trino/Presto.
- Formatar muda o que a consulta faz?
- Não. Só mudam os espaços em branco e, se você quiser, a caixa das palavras-chave. Identificadores, literais de string e a lógica da consulta continuam exatamente iguais.
- Posso formatar várias instruções de uma vez?
- Sim. Separe-as com ponto e vírgula e cada instrução é formatada separadamente, com uma linha em branco entre elas.
- Minha consulta é enviada para algum lugar?
- Não. A formatação roda no seu navegador, então consultas com nomes de tabelas ou dados de produção nunca saem da sua máquina.
- O formatador de SQL verifica erros na minha query?
- Não. Ele organiza os tokens, mas não valida a query contra um banco de dados ou um schema, então select a, from t é formatado sem reclamação. Os erros só aparecem quando o texto não pode ser lido de jeito nenhum no dialeto escolhido. Rode a query, ou faça um EXPLAIN, para encontrar os erros reais.
- Uma linha é seguro para queries com comentários --?
- Nem sempre. Um comentário -- vai até o fim da linha, então, quando a query é compactada em uma única linha, tudo o que vem depois do comentário passa a fazer parte dele. Remova os comentários -- ou reescreva-os como /* … */ antes de usar Uma linha. Comentários de bloco são seguros em uma única linha.
- Dá para formatar modelos dbt ou outro SQL com template?
- Não diretamente. Tags de template escritas com chaves duplas, assim como blocos de controle como if e for, não são SQL, então o formatador para com um erro de parse na primeira tag. Compile o modelo antes, por exemplo com dbt compile, e formate o SQL gerado.
O que faz um formatador de SQL?
Um formatador de SQL reescreve uma query para deixar sua estrutura visível. Cada cláusula, como SELECT, FROM, JOIN, WHERE, GROUP BY e ORDER BY, começa em uma linha própria, as colunas e condições abaixo dela ficam indentadas e os parênteses abrem um bloco indentado. Uma linha única como select id, email from users where active = true and (plan = 3 or trial = true) vira uma dúzia de linhas curtas em que dá para ver quais condições andam juntas.
A caixa das palavras-chave é questão de convenção. MAIÚSCULAS é o estilo tradicional, que destaca as palavras-chave dos nomes de tabelas e colunas, minúsculas é comum em guias de estilo mais recentes e em equipes de analytics, e Como digitado deixa as palavras-chave como estão quando você só quer arrumar o layout. Escolha 2 ou 4 espaços de indentação, ou Uma linha para compactar a query em uma string no código ou em uma busca de logs. Os comentários SQL são mantidos na saída.
Por que meu SQL não formata? Corrigindo “Parse error: Unexpected”
O formatador de SQL lê a query com as regras do dialeto selecionado, então a sintaxe de outro banco de dados causa um erro como “Parse error: Unexpected … at line 1 column 8”. Identificadores entre crases como `order` são sintaxe de MySQL, MariaDB, BigQuery e Spark, e falham no PostgreSQL ou no SQL Server. Colchetes como [order] são do SQL Server e falham no MySQL. Escolha o dialeto para o qual a query foi escrita e o erro geralmente desaparece.
Os placeholders também dependem do dialeto. Um ? do JDBC ou de um driver MySQL funciona em SQL padrão, MySQL, PostgreSQL e SQLite, $1 funciona no PostgreSQL, e o SQL Server espera parâmetros nomeados como @id, então um ? ali trava o formatador. Tags de template do dbt ou de outras ferramentas baseadas em Jinja nem são SQL e causam um erro de parse na primeira tag. Formate a query compilada.
Boas práticas de estilo SQL para queries legíveis
A formatação resolve o layout, e alguns hábitos deixam as queries mais fáceis de revisar. Escreva JOIN … ON explícito em vez de listar tabelas com vírgulas no FROM, dê às tabelas aliases curtos e significativos, como u para users e o para orders, e liste as colunas de que precisa em vez de SELECT *. Common table expressions escritas com WITH … AS dividem uma query longa em etapas nomeadas que se leem de cima para baixo.
Mantenha uma única configuração de formatação SQL por repositório: o mesmo dialeto, a mesma caixa das palavras-chave e a mesma indentação, para que reformatar uma query nunca gere ruído no code review. Para comparar duas versões de uma query longa, formate as duas aqui com configurações idênticas e cole-as no Diff de texto. Sem essa etapa, uma quebra de linha movida aparece como diferença, mesmo que a query seja a mesma.
Algo não está funcionando ou um resultado parece errado? Relatar um problema com esta ferramenta