Una consulta que llega como una sola línea de 400 caracteres es ilegible, y las consultas ilegibles esconden errores. Esta herramienta analiza tu SQL y lo dispone con cada cláusula en su propia línea. Analiza en lugar de limitarse a indentar, y por eso puede decirte cuándo algo está mal, y por eso importa elegir el dialecto correcto.
El selector de dialecto no es decoración
SQL es un estándar que nadie implementa exactamente, y las diferencias empiezan en algo tan básico como entrecomillar un nombre. MySQL y MariaDB envuelven los identificadores en comillas invertidas. PostgreSQL usa comillas dobles y rechaza las invertidas de plano. SQL Server usa corchetes. Una consulta escrita para uno y analizada como otro no solo se formatea raro: falla.
Puedes verlo aquí. Pega una consulta MySQL con nombres de columna entre comillas invertidas, selecciona PostgreSQL, y la salida se queda vacía: el analizador se ha negado correctamente a leer comillas invertidas como PostgreSQL, porque no lo son. Es la herramienta diciéndote algo cierto sobre tu consulta, no un fallo.
Las diferencias van más hondo que el entrecomillado. El límite de filas es LIMIT en MySQL, PostgreSQL y SQLite, TOP en SQL Server y FETCH FIRST en el estándar de verdad. La concatenación de cadenas es || casi en todas partes y CONCAT() en MySQL, donde || significa OR lógico salvo que se active un modo específico. Si estás moviendo una consulta entre motores, esas son las juntas por donde se agrieta.
Formatear comprueba la sintaxis, no la verdad
Dale a esta herramienta una consulta llena de disparates y te mostrará un error, porque analiza el texto de verdad. Eso es útil, y es también el límite de lo que puede decirte. Una consulta puede estar perfectamente bien formada y ser catastróficamente errónea igualmente.
No puede saber si tus tablas existen, si la columna por la que has hecho el join está indexada, si ese JOIN devolverá las filas que esperas o cincuenta millones. Un formato limpio no es una revisión de código. Lo que el formato te compra es poder ver la forma de la consulta, y una vez desplegada, una condición de join que falta o un WHERE que perdió los paréntesis tiende a hacerse visible de un modo que nunca lo es en una línea larga.
Un formateador no es una herramienta de seguridad
Merece decirse claramente porque la confusión es real. Formatear tu SQL no hace absolutamente nada contra la inyección SQL. No escapa nada, no valida nada, y una consulta construida pegando entrada de usuario dentro de una cadena es exactamente igual de peligrosa formateada que sin formatear: solo es más fácil de leer mientras te borra la tabla.
La única defensa real son las consultas parametrizadas: el texto SQL y los valores viajan por separado, así que un valor nunca puede reinterpretarse como sintaxis. Todos los controladores serios lo soportan. Si te encuentras buscando una función de escapado, eso suele ser señal de que la consulta se está construyendo al revés.
Las palabras clave no distinguen mayúsculas; los identificadores son la trampa
SELECT, select y SeLeCt son la misma palabra clave para cualquier motor, así que la opción de mayúsculas aquí es puro estilo: una convención extendida que hace la estructura ojeable, y nada más. Nadie te dará las gracias por palabras clave en minúscula, y tampoco se romperá nada.
Es en las mayúsculas de los identificadores donde viven los errores de verdad. PostgreSQL pliega los identificadores sin comillas a minúsculas, así que SELECT MyColumn en realidad pide mycolumn, y si creaste la columna como "MyColumn" con comillas, no se encontrará. El estándar dice que los identificadores se pliegan a mayúsculas, así que aquí PostgreSQL es técnicamente no conforme y todo el mundo ha aceptado en silencio convivir con ello.
MySQL es aún más raro: que los nombres de tabla distingan mayúsculas depende del sistema de archivos bajo el servidor. Las tablas son archivos, así que en Linux distinguen y en Windows y macOS no. Este es el mecanismo tras una clase de error concreta y penosa: una consulta que funciona en el Mac de un desarrollador y falla en producción sobre Linux, sin nada en el código que lo explique.
Preguntas frecuentes
¿Se envía mi consulta a un servidor?
No. Esta herramienta está marcada como "client": el analizador se ejecuta en la pestaña de tu navegador y el SQL nunca sale de tu máquina. Aquí importa más que en la mayoría de herramientas, porque las consultas reales llevan nombres de tablas, de columnas y a menudo valores literales de producción: la forma de tu esquema es información que probablemente no quieras entregar a un desconocido.
¿Formatear cambia lo que hace mi consulta?
No. El espacio en blanco entre tokens SQL no es significativo, así que la consulta reformateada es la misma consulta. Lo único a vigilar son los literales de cadena: el texto entre comillas es dato, y un formateador debe dejarlo intacto. Este lo hace. Si alguna vez te topas con un formateador que reindenta dentro de una cadena, deja de usarlo de inmediato.
¿Por qué mi consulta da error aquí pero funciona en mi base de datos?
Lo más probable es el dialecto. Selecciona el motor que usas de verdad en vez de Standard SQL: los motores aceptan muchas cosas que el estándar no contempla. También puede ser una extensión genuinamente específica del motor que el analizador no modela, en cuyo caso la consulta está bien y la herramienta sencillamente no es la autoridad sobre ella. Tu base de datos sí.
¿Debo usar palabras clave en mayúsculas?
Al motor le da igual. La convención existe porque separa el lenguaje de tus datos de un vistazo: en SELECT name FROM users, las palabras en mayúscula son SQL y las minúsculas son tuyas. La mayoría de los equipos la siguen, y la regla útil es adaptarse a lo que ya hay en tu código en vez de tener una opinión.
¿Puede formatear un procedimiento almacenado o un script de migración grande?
Maneja varias sentencias y te las separa. Las extensiones procedurales —PL/pgSQL, las rutinas de MySQL, el control de flujo de T-SQL— son un lenguaje distinto encima de SQL, y el soporte varía según el dialecto. Si el cuerpo de un procedimiento vuelve destrozado, ese es el límite que has tocado, y la respuesta es formatear las consultas de dentro en vez de la rutina entera.