T
sql format beautify database developer-tools

Formatador SQL: Embeleze e Formate suas Consultas SQL Instantaneamente

Melhore a legibilidade de suas consultas SQL com nosso formatador SQL online. Formate, embeleze e limpe facilmente scripts de banco de dados complexos.

2026-04-09 Usar esta ferramenta

Introdução

Todo desenvolvedor que trabalha com bancos de dados já se deparou com uma parede de SQL não formatado: palavras-chave em minúsculas, sem quebras de linha, nomes de tabelas colados às condições JOIN, tudo em uma única linha que se estende infinitamente para a direita. É quase impossível depurar, revisar em um pull request ou passar para um colega. A formatação SQL não é meramente cosmética — é uma disciplina profissional que melhora a legibilidade, reduz bugs, aplica padrões da equipe e torna a manutenção significativamente mais fácil.

Seja escrevendo um SELECT de cinco linhas ou um pipeline analítico de cem linhas com CTEs e funções de janela, uma formatação consistente é a diferença entre código que comunica intenção e código que a obscurece.

Uma Breve História do SQL

O SQL nasceu no início dos anos 1970 no Laboratório de Pesquisa da IBM em San José, onde o modelo relacional de Edgar F. Codd inspirou Donald D. Chamberlin e Raymond F. Boyce a desenvolverem uma linguagem chamada SEQUEL (Structured English Query Language). Mais tarde foi renomeada para SQL. A IBM a implementou no System R, e a Oracle tornou-se em 1979 a primeira empresa a vender um banco de dados SQL comercial.

O American National Standards Institute (ANSI) publicou o primeiro padrão SQL em 1986, seguido da ratificação ISO. Revisões subsequentes — SQL-89, SQL-92, SQL:1999, SQL:2003, SQL:2008, SQL:2011, SQL:2016 — adicionaram progressivamente recursos como gatilhos, procedimentos armazenados, consultas recursivas (CTEs), funções de janela e suporte a JSON.

Apesar do padrão, cada grande fornecedor de banco de dados introduziu extensões proprietárias, dando origem a dialetos: MySQL, PostgreSQL, Microsoft SQL Server (T-SQL), SQLite, Oracle PL/SQL e outros. Esses dialetos compartilham um núcleo comum, mas diferem na sintaxe para operações de string, funções de data, colunas de identidade e mais.

Fundamentos da Sintaxe SQL

Antes de formatar, é útil entender os blocos de construção. Uma instrução SELECT padrão segue esta ordem lógica:

SELECT   -- colunas a retornar
FROM     -- tabelas de origem
JOIN     -- tabelas relacionadas
WHERE    -- filtros em nível de linha
GROUP BY -- agrupamento de agregação
HAVING   -- filtros em nível de agregado
ORDER BY -- ordem de classificação
LIMIT    -- restrição de contagem de linhas

Cada cláusula tem um propósito distinto. WHERE filtra antes da agregação; HAVING filtra depois. GROUP BY recolhe múltiplas linhas em uma por grupo. ORDER BY se aplica por último (antes de LIMIT). Entender essa ordem ajuda a formatar consultas para que cada cláusula comece em sua própria linha, tornando o fluxo lógico imediatamente visível.

Convenções de Formatação

Não existe um único padrão universal, mas as seguintes convenções são amplamente adotadas:

Capitalização de Palavras-chave A maioria dos guias de estilo recomenda escrever palavras-chave SQL (SELECT, FROM, WHERE, JOIN, GROUP BY, HAVING, ORDER BY, LIMIT) em MAIÚSCULAS. Isso fornece contraste visual entre palavras-chave estruturais e identificadores definidos pelo usuário. Algumas equipes modernas preferem minúsculas por estética, e ferramentas como dbt popularizaram esse estilo. A regra principal: seja consistente.

Indentação Use 4 espaços (ou 2 espaços em estilos compactos) para indentar listas de colunas, cláusulas ON e predicados WHERE. Tabulações devem ser evitadas em bases de código compartilhadas devido à renderização inconsistente em diferentes editores.

Quebras de Linha Cada cláusula principal (SELECT, FROM, WHERE, GROUP BY, etc.) deve começar em sua própria linha. As listas de colunas em SELECT devem ser colocadas uma por linha, indentadas sob a palavra-chave. Isso facilita adicionar, remover ou comentar colunas individuais.

Posição da Vírgula Existem dois campos: vírgulas no final (fim da linha) e vírgulas no início (início da próxima linha). Vírgulas no final são mais naturais para a maioria dos programadores; vírgulas no início facilitam identificar uma vírgula faltando de relance. Escolha uma e mantenha-a.

Aliasing Sempre use a palavra-chave AS ao criar aliases (u AS usuario, não u usuario). Isso torna a intenção explícita e evita ambiguidade em consultas complexas.

Exemplo de Formatação Antes e Depois

-- ANTES (não formatado)
select u.id,u.name,o.total from users u inner join orders o on u.id=o.user_id where o.total>100 and u.active=1 order by o.total desc limit 10

-- DEPOIS (formatado)
SELECT
    u.id,
    u.name,
    o.total
FROM
    users u
    INNER JOIN orders o ON u.id = o.user_id
WHERE
    o.total > 100
    AND u.active = 1
ORDER BY
    o.total DESC
LIMIT 10

A versão formatada torna o relacionamento entre tabelas, condições de filtro e ordem de classificação imediatamente visíveis.

Comparação de Dialetos SQL

Embora o SQL seja padronizado, os dialetos diferem em aspectos importantes:

Recurso MySQL PostgreSQL SQL Server SQLite
Concatenação de strings CONCAT() || ou CONCAT() + ou CONCAT() ||
Auto-incremento AUTO_INCREMENT SERIAL / IDENTITY IDENTITY AUTOINCREMENT
Limitar linhas LIMIT n LIMIT n TOP n LIMIT n
Funções de data DATE(), NOW() CURRENT_DATE, NOW() GETDATE() DATE()
Distinção de maiúsculas Padrão: insensível Padrão: sensível Padrão: insensível Configurável

Entender essas diferenças é crítico ao portar consultas entre bancos de dados. Um formatador que conhece o dialeto alvo pode produzir saídas sintaticamente válidas mesmo para construções específicas do dialeto.

Guias de Estilo SQL

Dois guias de estilo amplamente referenciados ajudam as equipes a estabelecer consenso:

Guia de Estilo SQL de Simon Holywell (sqlstyle.guide) Este guia enfatiza o alinhamento de palavras raiz, o uso de "rios" de espaço em branco para separar visualmente as cláusulas, vírgulas no início e snake_case para identificadores. É opinativo, mas completo e amplamente usado em equipes de engenharia de dados.

Guia de Estilo SQL do Google O guia de estilo interno do Google (parcialmente público via documentação do BigQuery) favorece vírgulas no final, indentação de 4 espaços, palavras-chave em MAIÚSCULAS e quebra de linha para longas listas IN. Alinha-se bem com os padrões de codificação Java com os quais muitos engenheiros do Google estão familiarizados.

A maioria das equipes cria um guia de estilo interno leve derivado de um desses e o aplica por meio de formatação automática em pipelines CI.

Como os Formatadores SQL Funcionam

Um formatador SQL é, em sua essência, um front-end de compilador especializado. O processo tipicamente envolve três etapas:

1. Análise Léxica (Tokenização) A string SQL bruta é decomposta em um fluxo plano de tokens: palavras-chave (SELECT, FROM), identificadores (users, u), operadores (=, >), literais ('completed', 100), pontuação (,, ;) e espaços em branco/comentários. O analisador léxico não entende estrutura — ele apenas classifica caracteres.

2. Análise Sintática (Parsing) O fluxo de tokens é alimentado em um parser que constrói uma Árvore Sintática Abstrata (AST). Cada nó no AST representa uma construção lógica: um nó SelectStatement contém um nó ColumnList, um nó FromClause, um nó WhereClause, e assim por diante. O parser aplica regras gramaticais e detecta erros de sintaxe.

3. Re-emissão (Pretty Printing) O formatador percorre o AST e emite texto SQL de acordo com as regras de formatação: quebras de linha após palavras-chave de cláusula, indentação para nós filhos, espaços ao redor de operadores, transformações de capitalização de palavras-chave. Como a saída é derivada do AST em vez de manipulação de strings, o significado semântico da consulta é preservado perfeitamente.

Alguns formatadores mais simples ignoram a construção completa do AST e aplicam transformações baseadas em regras diretamente no fluxo de tokens. Isso é mais rápido, mas menos preciso para estruturas aninhadas complexas.

Padrões SQL Comuns com Exemplos

JOIN de Múltiplas Tabelas

SELECT
    c.name AS customer_name,
    p.name AS product_name,
    oi.quantity,
    oi.unit_price
FROM
    customers c
    INNER JOIN orders o ON c.id = o.customer_id
    INNER JOIN order_items oi ON o.id = oi.order_id
    INNER JOIN products p ON oi.product_id = p.id
WHERE
    o.status = 'shipped'
    AND o.created_at >= '2024-01-01'
ORDER BY
    c.name,
    o.created_at DESC;

Subconsulta

SELECT
    department,
    AVG(salary) AS avg_salary
FROM employees
WHERE salary > (
    SELECT AVG(salary)
    FROM employees
)
GROUP BY department
ORDER BY avg_salary DESC;

CTE (Expressão de Tabela Comum)

WITH monthly_revenue AS (
    SELECT
        DATE_TRUNC('month', created_at) AS month,
        SUM(amount) AS revenue
    FROM orders
    WHERE status = 'completed'
    GROUP BY 1
),
ranked_months AS (
    SELECT
        month,
        revenue,
        RANK() OVER (ORDER BY revenue DESC) AS rank
    FROM monthly_revenue
)
SELECT *
FROM ranked_months
WHERE rank <= 3;

Os CTEs melhoram a legibilidade ao decompor consultas complexas em blocos de construção nomeados e reutilizáveis. Eles são especialmente valiosos em SQL analítico onde as agregações intermediárias alimentam cálculos adicionais.

Funções de Janela

SELECT
    employee_id,
    department,
    salary,
    AVG(salary) OVER (PARTITION BY department) AS dept_avg,
    RANK() OVER (PARTITION BY department ORDER BY salary DESC) AS dept_rank
FROM employees;

Funções de janela (ROW_NUMBER, RANK, LAG, LEAD, SUM, AVG com OVER) estão entre os recursos mais poderosos do SQL. Uma formatação adequada — cada cláusula OVER na mesma linha que sua função — é essencial para a legibilidade.

Agregação com HAVING

SELECT
    category,
    COUNT(*) AS total_products,
    AVG(price) AS avg_price,
    MAX(price) AS max_price
FROM products
WHERE active = 1
GROUP BY category
HAVING COUNT(*) > 10
ORDER BY avg_price DESC;

Integração com IDEs e Ferramentas

VS Code O pacote npm sql-formatter alimenta várias extensões do VS Code. Configure a formatação ao salvar em settings.json:

"[sql]": { "editor.defaultFormatter": "mtxr.sqltools" }

JetBrains DataGrip DataGrip possui formatação SQL integrada em Código → Reformatar Código (Ctrl+Alt+L). As opções de estilo são configuráveis por dialeto de fonte de dados em Configurações → Editor → Estilo de Código → SQL.

DBeaver DBeaver suporta formatação SQL através do Editor SQL → Formatar SQL e permite configuração personalizada do formatador em Preferências → Editores → Editor SQL → Formatação.

Linha de Comando O pacote npm sql-formatter pode ser usado como uma ferramenta CLI:

npx sql-formatter --language postgresql --indent 4 query.sql

Melhores Práticas

  1. Formate cedo, formate com frequência. Execute o formatador antes de cada commit, não apenas antes da revisão de código.
  2. Concorde com um guia de estilo primeiro. Nenhum formatador pode substituir o consenso da equipe sobre convenções.
  3. Use aliases de forma consistente. Aliases curtos (1-2 letras) são adequados para consultas simples; aliases descritivos melhoram a legibilidade em consultas complexas.
  4. Nomeie CTEs de forma descritiva. monthly_revenue é melhor do que cte1 ou tmp.
  5. Comente a lógica complexa. Uma consulta bem formatada com comentários inline explicando regras de negócio não óbvias é muito mais fácil de manter do que SQL inteligente, mas silencioso.
  6. Faça linting de SQL na CI. Ferramentas como sqlfluff podem aplicar regras de formatação automaticamente em pipelines de pull requests.
  7. Mantenha CASE WHEN legível. Divida longas cadeias CASE WHEN em múltiplas linhas, um ramo por linha.
  8. Qualifique todas as referências de colunas. Em consultas de múltiplas tabelas, sempre prefixe os nomes de colunas com o alias da tabela (u.id em vez de apenas id).

Perguntas Frequentes

A formatação muda o comportamento da minha consulta? Não. Um formatador apenas altera espaços em branco, quebras de linha e capitalização de palavras-chave. A estrutura lógica e o plano de execução permanecem idênticos.

Um formatador pode corrigir erros de sintaxe? Não. Os formatadores requerem SQL sintaticamente válido (ou quase válido) para analisar corretamente. Use um linter como sqlfluff para detectar e explicar erros.

Qual estilo de capitalização de palavras-chave devo usar? MAIÚSCULAS para palavras-chave é a convenção mais tradicional e amplamente recomendada nas comunidades SQL e guias de estilo. No entanto, letras minúsculas são cada vez mais populares em dbt e ferramentas de dados modernas. Escolha uma para a sua equipe e aplique-a automaticamente.

Suporta procedimentos armazenados e blocos PL/SQL? O suporte varia. A maioria dos formatadores lida bem com DML (SELECT, INSERT, UPDATE, DELETE). Extensões procedurais (PL/SQL, lotes T-SQL, blocos BEGIN...END) requerem parsers conscientes do dialeto e variam em qualidade de suporte.

Meus dados SQL estão seguros ao usar formatadores online? Um bom formatador online processa tudo no lado do cliente no navegador usando JavaScript. Sua consulta nunca sai da sua máquina. Sempre verifique isso na política de privacidade da ferramenta antes de colar informações sensíveis de esquema.

Qual é a diferença entre um formatador e um linter? Um formatador transforma a apresentação do SQL sem alterar seu significado. Um linter (sqlfluff, SQLCheck) analisa o SQL em busca de violações de estilo, antipadrões e bugs potenciais, reportando problemas em vez de corrigi-los automaticamente.

Voltar ao blog Formatador SQL →