ToolActToolAct

Herramienta de Formato SQL

Entrada SQL
Salida formateada
Líneas: 1Caracteres: 0Bytes: 0
Líneas: 1Caracteres: 0

¿Qué es el Formateo SQL?

El formateador SQL estructura consultas SQL con indentación, saltos de línea y cláusulas claramente visibles. SELECT, JOIN, WHERE, GROUP BY, HAVING, ORDER BY, CTEs y subconsultas se vuelven más fáciles de leer, lo que ayuda en revisiones, depuración, enseñanza y análisis de reportes largos. El formateo también puede facilitar detectar cruces accidentales, condiciones saturadas o paréntesis mal colocados. No cambia la lógica de base de datos, no optimiza planes de ejecución, no garantiza portabilidad entre dialectos ni vuelve seguro SQL dinámico inseguro. En producción deben revisarse parametrización, permisos, índices, transacciones, bloqueos y el plan real en la base objetivo.

Cómo usar

Cómo usar

  1. Pega o escribe sentencias SQL en el cuadro de entrada izquierdo
  2. Selecciona el tamaño de sangría (2 espacios, 4 espacios o Tab) y el estilo de mayúsculas de las palabras clave
  3. Haz clic en 'Formatear' para embellecer el SQL o en 'Minificar' para eliminar los espacios en blanco
  4. Los resultados aparecen a la derecha con resaltado de sintaxis
  5. Haz clic en 'Copiar' o 'Descargar' para guardar los resultados

Notas sobre revisión de SQL

  • El formateo mejora la legibilidad, pero no valida permisos, índices, planes de ejecución ni la corrección de la lógica de negocio.
  • Antes de ejecutar SQL modificado, revisa manualmente las cláusulas generadas, los literales de cadena, los comentarios y la sintaxis específica de la base de datos.

Casos de uso

Convertir una consulta SQL densa en cláusulas revisablesPega una sentencia SELECT, JOIN, WHERE, GROUP BY, HAVING, ORDER BY, LIMIT o INSERT larga y el formateador separa las cláusulas principales en líneas independientes con sangría. El resultado es más fácil de revisar, depurar y explicar cuando un ORM o herramienta de reportes generó una sola línea densa.
Ajustar el estilo de mayúsculas de palabras clave al del equipo o la base de datosElige palabras clave en mayúsculas o minúsculas manteniendo protegidos los literales de cadena, comentarios y bloques delimitados por dólar. Esto estandariza fragmentos para archivos de migración, paneles, manuales y documentación interna sin buscar manualmente cada SELECT, JOIN, CASE o función de agregación. Como el análisis se realiza localmente en el navegador, las consultas que hacen referencia a nombres de tablas internas, flags de funciones sin publicar o esquemas de staging pueden reformatearse sin que el SQL pase por ningún embellecedor externo.
Comprimir SQL para transporte tras revisarloUsa el modo minificar para eliminar comentarios de bloque, comentarios de línea, espacios repetidos y espacios alrededor de comas o paréntesis. Resulta práctico para parámetros de URL, fixtures o valores de configuración compactos, pero debe aplicarse después de haber comprobado que la versión legible significa lo que esperas.
Formatear CTEs y subconsultas con sangría anidadaLas Common Table Expressions con cláusulas WITH y las subconsultas correlacionadas ganan un nivel adicional de sangría de modo que el SELECT exterior, el SELECT interior y los bloques UNION permanecen visualmente separados. Esto facilita el seguimiento de cadenas CTE recursivas y subconsultas EXISTS durante la revisión de código. La detección del dialecto importa aquí: PostgreSQL soporta `DISTINCT ON (col)`, MySQL usa identificadores con backtick e `IFNULL`, SQL Server usa corchetes `[table]` y `TOP n` en lugar de `LIMIT`, y Oracle mantiene `DUAL` y `ROWNUM`; el formateador alinea las palabras clave principales (SELECT, FROM, WHERE, GROUP BY, HAVING, ORDER BY) de forma consistente, pero la lista de tokens específica del dialecto es responsabilidad del usuario.
Detectar joins cartesianos accidentales antes de publicarFormatear un SELECT multi-tabla con cláusulas FROM separadas por comas pone de manifiesto cuando faltan condiciones JOIN ... ON. El diseño expandido muestra la lista de tablas desnuda donde aparece una multiplicación inesperada de filas en producción. Vigila los parámetros escritos como marcadores de posición de interrogación (usados por sentencias preparadas de MySQL y muchos ORMs) frente a la numeración dólar-1, dólar-2 (parámetros vinculados de PostgreSQL) y nombres con dos-puntos (Oracle y SQL*Plus); el formateador protege estos tokens para que no se traten como identificadores, pero el estilo de mayúsculas de las palabras clave debe coincidir con el elegido por el equipo (UPPER para migraciones, lower para legibilidad en revisiones de código).

Principio técnico

El formateo SQL es una canalización de tres etapas: un tokenizador escanea el texto crudo en un flujo de tokens (palabras clave, identificadores, literales, operadores, comentarios, espacios en blanco), un analizador agrupa esos tokens por estructura de cláusulas y un impresor recorre el resultado emitiendo nuevas líneas, sangrías y mayúsculas/minúsculas según una política de estilo. El tokenizador debe ser consciente del dialecto porque los delimitadores de cadenas e identificadores varían: SQL estándar usa comillas dobles para identificadores y comillas simples para cadenas, MySQL usa backticks para identificadores, SQL Server usa corchetes y PostgreSQL añade bloques delimitados por dólar ($$...$$ o $tag$...$tag$) que escapan cada carácter interno incluyendo las comillas.

La fase de impresión aplica una regla por cláusula: SELECT / FROM / WHERE / GROUP BY / HAVING / ORDER BY / LIMIT cada una comienza una nueva línea en la columna cero, las columnas proyectadas y las condiciones ON se indentan un nivel (2 espacios, 4 espacios o tabulación), las palabras clave JOIN (INNER / LEFT / RIGHT / FULL / CROSS) se alinean bajo FROM, CASE / WHEN / THEN / ELSE / END se apilan verticalmente y las subconsultas entre paréntesis y los CTE anidados dentro de WITH reciben un nivel adicional de sangría para que el SELECT exterior permanezca visualmente anclado. Los literales de cadena, los comentarios de línea (-- ...), los comentarios de bloque (/* ... */) y los bloques delimitados por dólar se tokenizan una vez y se copian sin cambios para que el espaciado interno nunca se modifique.

El ajuste de mayúsculas de las palabras clave se aplica en el momento de impresión, no mediante una expresión regular ciega sobre el origen; solo los tokens clasificados como RESERVED_KEYWORD se convierten a mayúsculas o minúsculas, por lo que un identificador llamado 'order' o 'user' dentro de backticks conserva su caso original. El soporte de dialectos es importante porque la lista de palabras reservadas difiere según el motor: PostgreSQL reconoce DISTINCT ON, RETURNING, ILIKE; MySQL añade IFNULL, LIMIT n,m, ENGINE=; SQL Server usa TOP n, OUTPUT, identificadores entre corchetes; Oracle añade DUAL, ROWNUM, MINUS en lugar de EXCEPT; BigQuery y Snowflake amplían el estándar con QUALIFY, EXCEPT (columnas) y literales de array/struct. El rendimiento es lineal respecto a la longitud del origen (O(n) tokens, O(n) bytes de salida), por lo que incluso scripts de migración de varios megabytes se formatean en milisegundos.
  • Tokenizador: escanea el origen en las clases RESERVED_KEYWORD, IDENTIFIER, STRING_LITERAL, NUMBER, OPERATOR, LINE_COMMENT (-- ...), BLOCK_COMMENT (/* ... */) y WHITESPACE; los comentarios y cadenas se preservan textualmente
  • Conciencia de dialecto: cadenas entre comillas simples (ANSI), identificadores con backtick (MySQL), identificadores entre corchetes (SQL Server), identificadores entre comillas dobles (PostgreSQL/estándar), bloques delimitados por dólar $$...$$ (PostgreSQL)
  • Distribución de cláusulas: SELECT, FROM, WHERE, GROUP BY, HAVING, ORDER BY, LIMIT cada una se ancla en la columna 0; las columnas proyectadas y las condiciones ON se indentan un nivel; las palabras clave JOIN se alinean bajo FROM
  • Sangría de CTE y subconsultas: las cláusulas WITH indentan el SELECT interior un nivel adicional; las subconsultas correlacionadas dentro de contextos EXISTS / IN / escalar reciben su propia sangría para que la consulta exterior permanezca anclada
  • Política de mayúsculas: se aplica en el momento de impresión por clase de token; solo los tokens RESERVED_KEYWORD se convierten a mayúsculas/minúsculas, por lo que identificadores como `order` o [user] conservan su caso original
  • Parámetros de enlace: marcadores de posición con signo de interrogación (sentencias preparadas de MySQL), enlaces numerados dólar-1/dólar-2 (PostgreSQL) y enlaces con nombre de dos puntos (Oracle/SQL*Plus) se tokenizan como PARAMETER y nunca se reformatean como identificadores
  • Complejidad: análisis léxico O(n) e impresión O(n) donde n = longitud del origen; scripts de migración de varios megabytes se formatean en milisegundos; comparable a la biblioteca npm sql-formatter, pgFormatter y el plugin Prettier SQL

Ejemplos

Formatear un SELECT denso con JOIN y 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;

Salida:
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 formateado para una cadena de configuración

Entrada (formateado, 6 líneas):
SELECT id, name
FROM   products
WHERE  price < 100
  AND  stock > 0
ORDER  BY name;

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

Formato de WITH (CTE) + subconsulta anidada

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);

Palabras clave en minúsculas (estilo de equipo)

Configuración: Sangría = 2 espacios, Palabras clave = minúsculas

Entrada:  SELECT * FROM Users WHERE Status=1;

Salida:
select *
from users
where status = 1;

Uso: coincide con archivos de migración estilo ORM de Ruby on Rails / Django

Preguntas frecuentes

¿Qué dialectos de SQL admite?

ANSI SQL estándar más palabras clave específicas de los dialectos más comunes: MySQL, PostgreSQL, MSSQL/T-SQL, SQLite, Oracle, BigQuery y Snowflake. Selecciona tu dialecto en el desplegable para que el formateador reconozca las palabras clave propias (LIMIT vs TOP, RETURNING, MERGE, etc.).

¿Qué opciones de estilo hay?

Palabras clave en mayúsculas o minúsculas, tamaño de indentación, comas al inicio o al final en listas de columnas, longitud máxima de línea para el ajuste y si se rompe antes o después de las palabras clave. Estas opciones suelen estar en un panel lateral.

¿Valida el SQL?

La mayoría de formateadores analizan el código de forma flexible y dejan pasar SQL dudoso sin cambios. Una validación real requiere conexión a una base de datos (o al menos un parser SQL real como sqlparse o sqlglot). Usa esto para el formato; usa tu IDE o tu base de datos para comprobar la sintaxis.

¿Formateará procedimientos almacenados y triggers?

La mayoría de versiones gestionan CREATE PROCEDURE / CREATE FUNCTION / triggers hasta donde lo permita el dialecto. Cuerpos largos con flujo de control (IF/ELSE/WHILE) se formatean correctamente; las extensiones del proveedor (palabras clave propias de T-SQL) requieren elegir el dialecto correcto.

¿Se sube mi consulta?

No. El formateo se hace en tu navegador con un parser SQL en JavaScript. El SQL pegado no se transmite. Aun así, nunca pegues credenciales reales de producción ni datos personales en ninguna herramienta web.

¿Por qué mis CTE y JOIN se indentan de forma rara?

Los formateadores no se ponen de acuerdo en la alineación de los CTE. Algunos indentan cada definición de CTE; otros las dejan pegadas a la izquierda. Los JOIN tienen también varios estilos válidos ('JOIN x ON' frente a 'JOIN x\n ON'). Elige la opción que coincida con el estilo de tu equipo y mantenla.

¿Puede minificar SQL?

Algunas versiones ofrecen un modo 'una sola línea' que elimina saltos de línea y espacios extra. Útil para incrustar SQL como cadena literal en código. Mantén siempre la versión formateada en el control de versiones: el SQL en una sola línea es ilegible para revisar.