Formateador SQL

Formatea y embellece SQL para PostgreSQL, MySQL, SQLite y más.

Acerca de esta herramienta

Pega una consulta, incluso una larga de una sola línea sacada de un log, y obtenla con una cláusula por línea. Elige el dialecto SQL, las mayúsculas de las palabras clave y la sangría.

Cómo se usa

  1. Pega una consulta, por ejemplo una larga de una sola línea copiada de un log o de la salida de depuración de un ORM.
  2. Elige el dialecto de tu base de datos para que se reconozcan sus palabras clave y su sintaxis.
  3. Elige las mayúsculas de las palabras clave (MAYÚSCULAS, minúsculas o tal como está) y la sangría, o Una línea para compactarla.
  4. Copia la consulta formateada.

Preguntas

¿Qué bases de datos se admiten?
SQL estándar, PostgreSQL, MySQL, MariaDB, SQLite, SQL Server (T-SQL), Oracle PL/SQL, BigQuery, Snowflake, Redshift, DuckDB, ClickHouse, Spark SQL y Trino/Presto.
¿Formatear cambia lo que hace la consulta?
No. Solo cambian los espacios en blanco y, si lo eliges, las mayúsculas de las palabras clave. Los identificadores, los literales de cadena y la lógica de la consulta se quedan exactamente igual.
¿Puedo formatear varias sentencias a la vez?
Sí. Sepáralas con punto y coma y cada sentencia se formatea por separado, con una línea en blanco entre ellas.
¿Se envía mi consulta a algún sitio?
No. El formateo se hace en tu navegador, así que las consultas con nombres de tablas o datos de producción nunca salen de tu equipo.
¿El formateador de SQL comprueba si mi consulta tiene errores?
No. Organiza los tokens, pero no valida la consulta contra una base de datos ni un esquema, así que select a, from t se formatea sin protestar. Los errores solo aparecen cuando el texto no se puede leer en absoluto en el dialecto elegido. Ejecuta la consulta, o lánzale un EXPLAIN, para encontrar los errores reales.
¿Es seguro usar Una línea con consultas que tienen comentarios --?
No siempre. Un comentario -- llega hasta el final de la línea, así que cuando la consulta se junta en una sola línea, todo lo que va después del comentario pasa a formar parte de él. Elimina los comentarios -- o reescríbelos como /* … */ antes de usar Una línea. Los comentarios de bloque son seguros en una sola línea.
¿Puedo formatear modelos de dbt u otro SQL con plantillas?
No directamente. Las etiquetas de plantilla escritas con dobles llaves, junto con los bloques de control como if y for, no son SQL, así que el formateador se detiene con un error de parseo en la primera etiqueta. Compila antes el modelo, por ejemplo con dbt compile, y formatea el SQL generado.

¿Qué hace un formateador de SQL?

Un formateador de SQL reescribe una consulta para que se vea su estructura. Cada cláusula, como SELECT, FROM, JOIN, WHERE, GROUP BY y ORDER BY, empieza en su propia línea, las columnas y condiciones que dependen de ella llevan sangría y los paréntesis abren un bloque con sangría. Una consulta de una sola línea como select id, email from users where active = true and (plan = 3 or trial = true) se convierte en una docena de líneas cortas donde se ve qué condiciones van juntas.

Las mayúsculas de las palabras clave son cuestión de convención. MAYÚSCULAS es el estilo tradicional que hace que las palabras clave destaquen sobre los nombres de tablas y columnas, minúsculas es habitual en las guías de estilo más recientes y en los equipos de analítica, y Tal como está deja las palabras clave sin tocar cuando solo quieres arreglar la disposición. Elige 2 o 4 espacios de sangría, o Una línea para compactar una consulta y usarla en una cadena de código o en una búsqueda de logs. Los comentarios SQL se conservan en la salida.

¿Por qué no se formatea mi SQL? Cómo solucionar “Parse error: Unexpected”

El formateador de SQL lee la consulta con las reglas del dialecto seleccionado, así que la sintaxis de otra base de datos provoca un error como “Parse error: Unexpected … at line 1 column 8”. Los identificadores entre comillas invertidas como `order` son sintaxis de MySQL, MariaDB, BigQuery y Spark, y fallan con PostgreSQL o SQL Server. Los corchetes como [order] son propios de SQL Server y fallan con MySQL. Elige el dialecto para el que se escribió la consulta y el error suele desaparecer.

Los marcadores de posición también dependen del dialecto. Un ? de JDBC o de un driver de MySQL funciona en SQL estándar, MySQL, PostgreSQL y SQLite, $1 funciona en PostgreSQL, y SQL Server espera parámetros con nombre como @id, así que un ? ahí detiene el formateador. Las etiquetas de plantilla de dbt u otras herramientas basadas en Jinja no son SQL y provocan un error de parseo en la primera etiqueta. Formatea en su lugar la consulta compilada.

Buenas prácticas de estilo SQL para consultas legibles

Formatear arregla la disposición, y unos pocos hábitos hacen que las consultas sean más fáciles de revisar. Escribe JOIN … ON explícitos en lugar de listar las tablas separadas por comas en FROM, da a las tablas alias cortos y con sentido, como u para users y o para orders, y nombra las columnas que necesitas en lugar de usar SELECT *. Las expresiones de tabla comunes escritas con WITH … AS dividen una consulta larga en pasos con nombre que se leen de arriba abajo.

Mantén una sola configuración de formato SQL por repositorio: el mismo dialecto, las mismas mayúsculas en las palabras clave y la misma sangría, para que reformatear una consulta nunca añada ruido a la revisión de código. Para comparar dos versiones de una consulta larga, formatea ambas aquí con la misma configuración y pégalas en Diff de textos. Sin ese paso, un salto de línea movido aparece como diferencia aunque la consulta sea la misma.

¿Algo no funciona o un resultado parece incorrecto? Informar de un problema con esta herramienta