Formatador de SQL

Transforme um SQL ilegível de uma linha só em uma consulta bem indentada — 18 dialetos, tudo no seu navegador.

Como usar

  1. Cole seu SQL no campo: uma consulta, uma stored procedure ou um arquivo de migração inteiro. "Carregar um exemplo bagunçado" preenche o campo com uma consulta propositalmente feia.
  2. Escolha o dialeto que o seu banco fala — PostgreSQL, MySQL, SQL Server e outros quinze aceitam sintaxes que o SQL padrão rejeita — e depois escolha a caixa das palavras-chave e a indentação que você usa.
  3. Clique em "Formatar SQL" e depois copie o resultado ou baixe o arquivo .sql — a consulta nunca é enviada.

Sobre esta ferramenta

SQL raramente chega legível: uma linha infinita cuspida por um ORM, todas as palavras-chave em minúsculas no log de consultas lentas, a indentação destruída por um cliente de chat. Reformatar tudo na mão só para conseguir ler consome dez minutos — e é na leitura que estão os bugs: uma condição de join que virou filtro sem ninguém notar, um OR que abrange mais do que o autor imaginava, uma subconsulta três níveis abaixo. Cole aqui e o SQL volta com uma cláusula por linha, aninhamento alinhado e palavras-chave na caixa que você preferir.

O trabalho é feito por um parser de verdade, não por um monte de expressões regulares. A consulta é tokenizada, entendida como uma árvore de cláusulas e impressa de novo, e é por isso que os comentários ficam na linha em que foram escritos, os literais de texto sobrevivem intactos mesmo quando contêm palavras como SELECT ou FROM, e uma window function mantém o bloco OVER (PARTITION BY … ORDER BY …) devidamente aninhado. São oferecidos dezoito dialetos — Standard SQL, PostgreSQL, MySQL, MariaDB, SQLite, SQL Server (T-SQL), Oracle PL/SQL, BigQuery, Snowflake, Redshift, Spark, Trino, Hive, Db2, Db2 for i, TiDB, SingleStore e N1QL — e a escolha não é decoração: o dollar-quoting do PostgreSQL ($$body$$) e os colchetes do T-SQL ([dbo].[table]) são erros de sintaxe no SQL padrão e formatam perfeitamente com o dialeto certo. Placeholders como ?, :name, $1 e @name são reconhecidos em todos os dialetos e repassados literalmente, então um SQL copiado direto de um log de consultas não é estragado.

Duas ressalvas honestas. O formatador só verifica se o texto é um SQL gramaticalmente válido para o dialeto escolhido: ele não sabe nada sobre as suas tabelas, então vai formatar uma consulta que referencia uma coluna inexistente, e nunca executa nada. Quando o texto não pode ser interpretado, ele diz onde o parser desistiu, com linha e coluna, em vez de devolver uma bagunça meio formatada. A privacidade é o motivo para formatar aqui em vez de num site qualquer: consultas de produção carregam nomes de tabelas, regras de negócio e, às vezes, dados pessoais. A biblioteca (sql-formatter, licença MIT, servida por vai.la e baixada só na sua primeira formatação) roda dentro do seu navegador.

Perguntas frequentes

Meu SQL sai do meu navegador?

Não. A consulta é interpretada e reimpressa por JavaScript no seu próprio dispositivo — nada é enviado, registrado ou armazenado. Isso importa, porque consultas reais expõem o seu esquema, as suas regras de negócio e, às vezes, dados pessoais escritos em literais. Depois da primeira formatação, você pode se desconectar da internet que ela continua funcionando.

Qual dialeto devo escolher?

O que o seu banco fala. O SQL padrão cobre a maioria das consultas comuns, mas sintaxes específicas de cada banco exigem o dialeto correspondente: [colchetes] pedem SQL Server (T-SQL), $$aspas de cifrão$$ pedem PostgreSQL. Um erro de sintaxe em um SQL válido costuma se resolver trocando o dialeto.

Formatar pode mudar o que a minha consulta faz?

Não. Só mudam os espaços em branco, as quebras de linha e a caixa das palavras-chave. Identificadores, literais de texto, números e comentários voltam exatamente como foram digitados, então a consulta formatada é equivalente à original.

Por que aparece que o meu SQL não pôde ser interpretado?

Porque o parser esbarrou em algo que não se encaixa na gramática, na linha e na coluna indicadas. Três causas comuns: um erro de digitação, como vírgula, aspas ou parêntese faltando; um trecho que não é um comando completo; ou sintaxe específica de um banco com o dialeto errado selecionado.

Ele lida com placeholders de um ORM ou de prepared statements?

Sim. Placeholders posicionais (?), numerados ($1) e nomeados (:name, @name) são reconhecidos em todos os dialetos e reimpressos sem alteração, então dá para colar direto de um log de consultas ou da saída de depuração de um framework.

Posso formatar um arquivo de migração inteiro?

Pode. Comandos separados por ponto e vírgula são formatados um após o outro, com uma linha em branco entre eles. A entrada é limitada a 300.000 caracteres para que a página nunca trave; acima disso, divida o arquivo.

Ferramentas relacionadas

Links longos? Encurte de graça

O Vai.la transforma qualquer URL em um link curto com estatísticas de cliques, QR Code e seu próprio biolink.

O Vai.la não se responsabiliza pelo uso das ferramentas nem por decisões tomadas com base nos seus resultados.