Formate, minifique e leia consultas SQL de MySQL, PostgreSQL, SQL Server, Oracle e outros dialetos, com separação por comando, resumo do que a consulta toca e alertas de revisão.
Consultas SQL escritas às pressas viram uma linha gigante e ilegível, difícil de revisar e de versionar. Esta bancada faz três coisas com esse texto. Primeiro, formata: reescreve a consulta com quebras de linha, indentação consistente e alinhamento de cláusulas (SELECT, FROM, JOIN, WHERE, GROUP BY), com caixa das palavras-chave e dos identificadores configuráveis de forma independente e vírgulas à direita ou à esquerda. Segundo, minifica: remove quebras, indentação e comentários para caber em uma linha de log, em uma variável de código ou em um arquivo de configuração. Terceiro, lê: separa um script em comandos numerados e copiáveis, extrai as tabelas, colunas, junções e cláusulas de cada comando e levanta alertas de revisão como SELECT *, DELETE ou UPDATE sem WHERE e JOIN sem condição. São oito dialetos (SQL padrão, MySQL, MariaDB, PostgreSQL, SQLite, BigQuery, T-SQL e PL/SQL), e literais, comentários, crases, colchetes e blocos com cifrão do PostgreSQL são preservados exatamente como estavam. Tudo roda localmente, então é seguro trabalhar com nomes reais de tabelas e colunas.
No modo formatar, cada cláusula principal (SELECT, FROM, JOIN, WHERE, GROUP BY, ORDER BY) começa uma linha, a lista de colunas e as condições são quebradas e tudo recebe indentação consistente. Você define a caixa das palavras-chave e a dos identificadores separadamente, a indentação em 2, 4 ou 8 espaços e se as vírgulas ficam no fim da linha ou no começo da linha seguinte, estilo comum em times que revisam diffs de SQL.
No modo minificar, quebras de linha, indentação e comentários saem e o comando vira uma linha só. Duas decisões conservadoras: os espaços em volta dos operadores são mantidos, porque colar um sinal de menos em outro transformaria a expressão em um comentário de linha, e comentários de otimizador (os que começam com /*+ ou /*!) são preservados, porque carregam instrução para o banco e não são decoração.
Ao colar um dump ou uma migration com vários comandos, a ferramenta separa o script nos pontos e vírgulas que realmente encerram um comando. Ponto e vírgula dentro de um literal, de um comentário ou de um bloco BEGIN e END não conta como separador. Cada comando aparece numerado, formatado e com seu próprio botão de copiar.
O resumo lê a estrutura de cada comando e responde ao que se pergunta ao herdar uma consulta longa: quais tabelas ela toca e com quais apelidos, quais colunas o SELECT projeta, quais tipos de junção existem e se cada uma tem condição, quais cláusulas estão presentes (WHERE, GROUP BY, HAVING, ORDER BY, LIMIT), quais CTEs foram declaradas, quantas subconsultas há e quais parâmetros a consulta espera receber.
Os alertas são leitura estática do texto: SELECT *, DELETE ou UPDATE sem WHERE, JOIN sem ON nem USING, INSERT sem lista de colunas, tabelas separadas por vírgula no FROM, comando que remove dados ou estrutura, e aspas ou comentário abertos sem fechamento. Cada um aponta o comando e a evidência encontrada.
O que eles não são: diagnóstico de desempenho. Se uma consulta vai ser rápida ou lenta depende do plano de execução, dos índices, das estatísticas e do volume real de cada tabela, coisas que não estão no texto e que esta ferramenta não tem como saber. Um SELECT * pode ser perfeitamente adequado, e uma consulta sem nenhum alerta pode ser lenta. Para custo real, use EXPLAIN (ou EXPLAIN ANALYZE) no seu banco.
Formatar antes de abrir um pull request, de salvar uma migration ou de colar na documentação padroniza o estilo do time e deixa o diff legível. Minificar ajuda quando a consulta precisa caber em uma linha de log, em uma string de código ou em um campo de configuração. O resumo e os alertas ajudam principalmente na leitura de uma consulta herdada, aquela de sessenta linhas que ninguém lembra por que ficou assim.
Sobre limites: a ferramenta mexe apenas em espaços, quebras e caixa, nunca na lógica, e não valida nem executa nada. Se um comando não puder ser interpretado no dialeto escolhido, ele é devolvido exatamente como estava e marcado na revisão, em vez de ser perdido ou reescrito na sorte. A separação de blocos procedurais (BEGIN, CASE, LOOP) é heurística: em pacotes PL/SQL muito aninhados a numeração pode não bater, mas nenhum caractere do seu texto é descartado.
Cole o código no seu HTML e a ferramenta aparece na sua página, sem a navegação e sem os anúncios do J-Kit. Ela continua rodando no navegador de quem visita o seu site.
<iframe
src="https://jkit.tools/embed/pt-BR/formatador-sql"
width="100%"
height="600"
style="border:0"
loading="lazy"
title="Formatador de SQL"
></iframe>Estas referências ajudam a contextualizar fórmulas, padrões, APIs e limitações usadas nesta página. Elas não substituem validação profissional quando o resultado tiver impacto jurídico, financeiro, médico ou operacional.
O formatador suporta SQL padrão, MySQL, MariaDB, PostgreSQL, SQLite, BigQuery, SQL Server (T-SQL) e Oracle (PL/SQL). O dialeto escolhido também define como o texto é lido: crases em MySQL, colchetes no SQL Server, aspas duplas como identificador no PostgreSQL e blocos com cifrão (o $$ do PostgreSQL) são reconhecidos e preservados.
WITH
ativos AS (
SELECT
id,
name
FROM
users
WHERE
status = 'active'
)
SELECT
a.id,
a.name,
count(o.id) AS orders,
sum(o.total) AS revenue
FROM
ativos a
LEFT JOIN orders o ON o.user_id = a.id
WHERE
o.created_at > '2024-01-01'
GROUP BY
a.id,
a.name
HAVING
count(o.id) > 3
ORDER BY
revenue DESC
LIMIT
10;WITH
ativos AS (
SELECT
id,
name
FROM
users
WHERE
status = 'active'
)
SELECT
a.id,
a.name,
count(o.id) AS orders,
sum(o.total) AS revenue
FROM
ativos a
LEFT JOIN orders o ON o.user_id = a.id
WHERE
o.created_at > '2024-01-01'
GROUP BY
a.id,
a.name
HAVING
count(o.id) > 3
ORDER BY
revenue DESC
LIMIT
10;Tudo acontece no seu navegador. Nenhuma consulta e nenhum arquivo é enviado a servidores.