ToolActToolAct

Ferramenta de Formatação SQL

SQL de Entrada
Saída Formatada
Linhas: 1Caracteres: 0Bytes: 0
Linhas: 1Caracteres: 0

O que é Formatação SQL?

O formatador SQL estrutura consultas com indentação, quebras de linha e cláusulas claramente visíveis. SELECT, JOIN, WHERE, GROUP BY, HAVING, ORDER BY, CTEs e subconsultas ficam mais fáceis de ler, ajudando revisões, depuração, ensino e análise de relatórios longos. A formatação também pode revelar joins cruzados acidentais, condições confusas ou parênteses mal posicionados. Ela não muda a lógica do banco, não otimiza planos de execução, não garante portabilidade entre dialetos nem torna SQL dinâmico inseguro seguro. Em produção, parametrização, permissões, índices, transações, bloqueios e o plano real da consulta ainda precisam de revisão.

Como Usar

Como usar

  1. Cole ou insira instruções SQL na caixa de entrada à esquerda
  2. Selecione o tamanho da indentação (2 espaços, 4 espaços ou Tab) e a capitalização das palavras-chave
  3. Clique em 'Formatar' para embelezar o SQL ou 'Minificar' para remover espaços em branco
  4. Os resultados aparecem à direita com destaque de sintaxe
  5. Clique em 'Copiar' ou 'Baixar' para salvar os resultados

Notas de Revisão de SQL

  • A formatação melhora a legibilidade, mas não valida permissões, índices, planos de execução nem correção de regras de negócio.
  • Antes de executar SQL alterado, revise manualmente as cláusulas geradas, literais de string, comentários e sintaxe específica do banco de dados.

Casos de uso

Transformar uma consulta SQL densa em cláusulas revisáveisCole um longo SELECT, JOIN, WHERE, GROUP BY, HAVING, ORDER BY, LIMIT ou INSERT e o formatador quebra as cláusulas principais em linhas separadas com recuo. O resultado é mais fácil de revisar, depurar e explicar quando uma ORM ou ferramenta de relatório gerou uma única linha densa.
Padronizar maiúsculas de palavras-chave conforme o estilo da equipeEscolha palavras-chave em maiúsculas ou minúsculas mantendo literais de string, comentários e blocos delimitados protegidos. Isso padroniza trechos para arquivos de migração, dashboards, runbooks e documentação interna sem precisar caçar manualmente cada SELECT, JOIN, CASE ou função de agregação. Como a análise acontece localmente no navegador, consultas que referenciam nomes de tabela internos, flags de funcionalidade não lançadas ou schemas de staging podem ser reformatadas sem que o SQL passe por qualquer embelezador de terceiros.
Comprimir SQL para transporte após revisá-loUse o modo minificar para remover comentários de bloco, comentários de linha, espaços em branco repetidos e espaços ao redor de vírgulas ou parênteses. É útil para parâmetros de URL, fixtures ou valores de configuração compactos, mas deve ser aplicado depois de já ter verificado que a versão legível significa o que você espera.
Formatar CTEs e subconsultas com recuo aninhadoCommon Table Expressions com cláusulas WITH e subconsultas correlacionadas ganham um nível extra de recuo para que o SELECT externo, o SELECT interno e os blocos UNION permaneçam visualmente separados. Isso facilita o acompanhamento de cadeias recursivas de CTE e subconsultas EXISTS durante a revisão de código. A detecção de dialeto é importante aqui: PostgreSQL suporta DISTINCT ON (col), MySQL usa identificadores com backtick e IFNULL, SQL Server usa colchetes [table] e TOP n em vez de LIMIT, e Oracle mantém DUAL e RNUM; o formatador alinha as principais palavras-chave (SELECT, FROM, WHERE, GROUP BY, HAVING, ORDER BY) de forma consistente, mas a lista de tokens específica do dialeto é responsabilidade do usuário verificar.
Detectar joins cartesianos acidentais antes de ir para produçãoFormatar um SELECT com múltiplas tabelas e cláusulas FROM separadas por vírgulas torna evidente quando as condições JOIN ... ON estão faltando. O layout expandido revela a lista de tabelas cruas onde uma multiplicação inesperada de linhas pode aparecer em produção. Observe parâmetros escritos como placeholders de interrogação (usados por prepared statements do MySQL e muitas ORMs) versus numeração dollar-1, dollar-2 (parâmetros de ligação do PostgreSQL) e binds nomeados com dois-pontos (Oracle e SQL*Plus); o formatador protege esses tokens de serem tratados como identificadores, mas o maiúsculas/minúsculas das palavras-chave ainda precisa corresponder ao estilo escolhido pela equipe (maiúsculas para migrações, minúsculas para legibilidade em revisão de código).

Princípio técnico

A formatação de SQL é um pipeline de três estágios: um tokenizer escaneia o texto bruto em um fluxo de tokens (palavras-chave, identificadores, literais, operadores, comentários, espaços em branco), um parser agrupa esses tokens pela estrutura de cláusulas, e um percorre o resultado emitindo novas linhas, recuo e capitalização de acordo com uma política de estilo. O tokenizer precisa ser sensível ao dialeto porque os delimitadores de strings e identificadores diferem: ANSI SQL usa aspas duplas para identificadores e aspas simples para strings, MySQL usa backticks para identificadores, SQL Server usa colchetes, e PostgreSQL adiciona blocos com delimitador dólar ($$...$$ ou $tag$...$tag$) que escapam todo caractere interno, incluindo aspas.

A etapa de impressão aplica uma regra por cláusula: SELECT / FROM / WHERE / GROUP BY / HAVING / ORDER BY / LIMIT cada uma inicia uma nova linha na coluna zero, colunas projetadas e condições ON recebem um nível de recuo (2 espaços, 4 espaços ou tab), palavras-chave JOIN (INNER / LEFT / RIGHT / FULL / CROSS) alinham-se abaixo de FROM, CASE / WHEN / THEN / ELSE / END são empilhados verticalmente, e subconsultas entre parênteses e CTEs aninhadas dentro de WITH recebem um nível adicional de recuo para que o SELECT externo permaneça visualmente ancorado. Literais de string, comentários de linha (-- ...), comentários de bloco (/* ... */) e blocos com delimitador dólar são tokenizados uma vez e copiados inalterados, de forma que o espaçamento interno nunca é tocado.

A capitalização de palavras-chave é aplicada no momento da impressão, não por regex cego sobre o código-fonte — apenas tokens classificados como RESERVED_KEYWORD são convertidos para maiúsculas ou minúsculas, então um identificador chamado 'order' ou 'user' dentro de backticks mantém sua capitalização original. O suporte a dialetos é importante porque a lista de palavras reservadas difere por mecanismo: PostgreSQL reconhece DISTINCT ON, RETURNING, ILIKE; MySQL adiciona IFNULL, LIMIT n,m, ENGINE=; SQL Server usa TOP n, OUTPUT, identificadores com colchetes; Oracle adiciona DUAL, ROWNUM, MINUS no lugar de EXCEPT; BigQuery e Snowflake estendem o padrão com QUALIFY, EXCEPT (colunas) e literais array/struct. O desempenho é linear no comprimento do código-fonte (O(n) tokens, O(n) bytes de saída), então mesmo scripts de migração de vários megabytes são formatados em milissegundos.
  • Tokenizer: escaneia o código-fonte em classes RESERVED_KEYWORD, IDENTIFIER, STRING_LITERAL, NUMBER, OPERATOR, LINE_COMMENT (-- ...), BLOCK_COMMENT (/* ... */) e WHITESPACE; comentários e strings são preservados literalmente
  • Sensibilidade a dialetos: strings com aspas simples (ANSI), identificadores com backtick (MySQL), identificadores com colchetes (SQL Server), identificadores com aspas duplas (PostgreSQL/padrão), blocos com delimitador dólar $$...$$ (PostgreSQL)
  • Layout de cláusulas: SELECT, FROM, WHERE, GROUP BY, HAVING, ORDER BY, LIMIT cada uma ancora na coluna 0; colunas projetadas e condições ON recebem um nível de recuo; palavras-chave JOIN alinham-se abaixo de FROM
  • Recuo de CTE e subconsultas: cláusulas WITH recuam o SELECT interno um nível extra; subconsultas correlacionadas dentro de EXISTS / IN / contextos escalares recebem seu próprio recuo para que a consulta externa permaneça ancorada
  • Política de capitalização: aplicada no momento da impressão por classe de token — apenas tokens RESERVED_KEYWORD são convertidos para maiúsculas/minúsculas, então identificadores como `order` ou [user] mantêm sua capitalização original
  • Parâmetros de ligação: placeholders de interrogação (prepared statements do MySQL), binds numerados dollar-1/dollar-2 (PostgreSQL) e binds com nome de dois-pontos (Oracle/SQL*Plus) são tokenizados como PARAMETER e nunca reformatados como identificadores
  • Complexidade: O(n) para análise léxica e O(n) para impressão, onde n = comprimento do código-fonte — scripts de migração de vários megabytes são formatados em milissegundos; comparável à biblioteca npm sql-formatter, pgFormatter e ao plugin Prettier SQL

Exemplos

Formatar um SELECT denso com JOIN e WHERE

Entrada:  select u.id,u.name,o.total from users u left join orders o on o.user_id=u.id where u.status='active' and o.created_at>='2026-01-01' order by o.total desc limit 10;

Saída:
SELECT u.id, u.name, o.total
FROM users u
LEFT JOIN orders o ON o.user_id = u.id
WHERE u.status = 'active'
  AND o.created_at >= '2026-01-01'
ORDER BY o.total DESC
LIMIT 10;

Minificar SQL formatado para uma string de configuração

Entrada (formatada, 6 linhas):
SELECT id, name
FROM   products
WHERE  price < 100
  AND  stock > 0
ORDER  BY name;

Saída minificada (1 linha, 78 caracteres):
SELECT id,name FROM products WHERE price<100 AND stock>0 ORDER BY name;

Formatação de WITH (CTE) + subconsulta aninhada

WITH recent_orders AS (
  SELECT user_id, SUM(total) AS spend
  FROM   orders
  WHERE  created_at >= NOW() - INTERVAL '30 days'
  GROUP  BY user_id
)
SELECT u.name, r.spend
FROM   users u
JOIN   recent_orders r ON r.user_id = u.id
WHERE  r.spend > (SELECT AVG(spend) FROM recent_orders);

Palavras-chave em minúsculas (estilo de equipe)

Configurações: Indentação = 2 espaços, Palavras-chave = minúsculas

Entrada:  SELECT * FROM Users WHERE Status=1;

Saída:
select *
from users
where status = 1;

Uso: combina com arquivos de migração estilo ORM do Ruby on Rails / Django

Perguntas frequentes

Quais dialetos SQL são suportados?

ANSI SQL padrão mais palavras-chave comuns específicas de dialetos: MySQL, PostgreSQL, MSSQL/T-SQL, SQLite, Oracle, BigQuery, Snowflake. Selecione o dialeto alvo no menu suspenso para que o formatador conheça as palavras-chave específicas (LIMIT vs TOP, RETURNING, MERGE etc.).

Quais opções de estilo estão disponíveis?

Palavras-chave em maiúsculas ou minúsculas, tamanho da indentação, vírgulas no início ou no fim em listas de colunas, comprimento máximo de linha para quebra automática e se a quebra deve ocorrer antes ou depois das palavras-chave. A página normalmente exibe as opções em um painel lateral.

Ele valida o SQL?

A maioria dos formatadores faz parsing flexível e deixa SQL questionável passar inalterado. Validação real requer uma conexão com banco de dados (ou pelo menos um parser SQL real como sqlparse, sqlglot). Use isto para o layout; use sua IDE ou o banco real para verificação de sintaxe.

Ele formata stored procedures e triggers?

A maioria das versões lida com CREATE PROCEDURE / CREATE FUNCTION / triggers até o limite suportado pelo dialeto. Corpos muito longos com fluxo de controle (IF/ELSE/WHILE) são formatados corretamente; extensões de fornecedor (palavras-chave específicas de T-SQL) precisam que o dialeto correto esteja selecionado.

Minha query é enviada para algum servidor?

Não. A formatação roda no seu navegador usando um parser SQL em JavaScript. O SQL colado não é transmitido. Dito isso, nunca cole credenciais reais de produção ou dados pessoais (PII) em qualquer ferramenta web.

Por que minhas CTEs e joins ficam com indentação estranha?

Formatadores diferentes discordam sobre o alinhamento de CTEs. Alguns indentam cada definição de CTE; outros as mantêm alinhadas à esquerda. Joins também têm múltiplos estilos válidos ('JOIN x ON' vs 'JOIN x\n ON'). Escolha a opção que combina com o estilo da sua equipe e mantenha-a.

Ele minifica SQL?

Algumas versões oferecem um modo 'uma linha' que remove quebras de linha e espaços em branco extras. Útil para embutir SQL no código como string literal. Sempre mantenha a versão formatada no controle de versão — SQL em uma linha só é ilegível para revisão.