Guía del Formateador SQL: Escribe Consultas Más Limpias y Mantenibles

Todo desarrollador ha pasado por esto. Extraes una consulta lenta del registro de la aplicación, la copias en tu editor y te encuentras mirando una cadena de 300 caracteres en minúsculas sin espacios, sin saltos de línea y sin compasión. O encuentras una respuesta en Stack Overflow con exactamente la consulta que necesitas, pero está escrita en una sola línea. O tu ORM registra el SQL que genera —como una cadena concatenada. En todos estos casos, la consulta sin formato es técnicamente correcta pero prácticamente ilegible.

Formatear SQL no es una cuestión estética. Se trata de poder entender de un vistazo lo que hace una consulta: de qué tablas lee, por qué condiciones filtra y qué columnas devuelve. Una consulta bien formateada puede revisarse, depurarse y optimizarse en minutos. Una sin formato puede consumir horas.

El Formateador SQL de BrowseryTools te permite pegar cualquier consulta SQL y darle formato al instante con sangría apropiada, palabras clave en mayúsculas y separación de cláusulas —todo procesado localmente en tu navegador, sin que ninguna consulta se envíe jamás a un servidor.

Por Qué el SQL sin Formato Es tan Doloroso

SQL es uno de los pocos lenguajes en los que los desarrolladores trabajan habitualmente con código que no escribieron y que no pueden reformatear en el origen. Considera las tres fuentes más comunes de SQL feo:

• Consultas generadas por ORM. Hibernate, SQLAlchemy, ActiveRecord y similares generan SQL dinámicamente. Cuando habilitas el registro de consultas para depurar un problema de rendimiento, obtienes el SQL en bruto generado —generalmente una sola línea con valores de parámetros dinámicos, alias como t0_ y condiciones de join que requieren varias lecturas para interpretarse.
• Registros de consultas de bases de datos en producción. El registro de consultas lentas de MySQL y pg_stat_statements de PostgreSQL almacenan las consultas tal como se enviaron —sin formato aplicado. Son invaluables para el análisis de rendimiento pero casi imposibles de leer sin reformatear antes.
• Stack Overflow y documentación en una línea. El código compartido en respuestas y documentación a menudo se comprime en una sola línea para ahorrar espacio vertical. La lógica es correcta pero el formato dificulta adaptarla a tu propio esquema.

Antes y Después: la Misma Consulta, Formateada

Aquí tienes una consulta realista tal como podría aparecer en un registro de consultas lentas o en la salida de un ORM —todo en una línea con palabras clave en minúsculas:

select u.id,u.name,u.email,count(o.id) as order_count,sum(o.total) as total_spent from users u left join orders o on u.id=o.user_id where u.created_at>='2024-01-01' and u.status='active' group by u.id,u.name,u.email having count(o.id)>0 order by total_spent desc limit 20;

Después de formatear con convenciones SQL consistentes, la misma consulta se vuelve inmediatamente legible:

SELECT
    u.id,
    u.name,
    u.email,
    COUNT(o.id)  AS order_count,
    SUM(o.total) AS total_spent
FROM users AS u
LEFT JOIN orders AS o
    ON u.id = o.user_id
WHERE u.created_at >= '2024-01-01'
  AND u.status = 'active'
GROUP BY
    u.id,
    u.name,
    u.email
HAVING COUNT(o.id) > 0
ORDER BY total_spent DESC
LIMIT 20;

La estructura es ahora inmediatamente visible: puedes ver que se trata de un informe de usuarios que extrae conteos de pedidos y totales de gasto, filtrado a usuarios activos desde 2024, agrupado por usuario y limitado a los 20 mayores compradores. Eso tomó cinco segundos entenderlo —en lugar de cinco minutos.

Convenciones de Formato SQL

No existe una guía de estilo SQL oficial única, pero ha surgido un conjunto de convenciones ampliamente aceptadas en toda la industria. Seguirlas hace que tu SQL sea legible para cualquier desarrollador que conozca el lenguaje.

Palabras Clave en Mayúsculas

Las palabras clave SQL —SELECT, FROM, WHERE, JOIN, ON, GROUP BY, ORDER BY, HAVING, LIMIT, INSERT, UPDATE, DELETE, WITH, AS, AND, OR, NOT, IN, LIKE, BETWEEN, IS NULL— deben ir en mayúsculas. Los nombres de tabla, columna, alias y literales de cadena se mantienen en su caso natural. Este contraste visual entre PALABRAS_CLAVE e identificadores hace que las consultas sean legibles de un vistazo.

Cada Cláusula Principal en Su Propia Línea

Cada cláusula de nivel superior comienza en una nueva línea: SELECT, FROM, WHERE, GROUP BY, HAVING, ORDER BY, LIMIT. Esto da a la consulta un esqueleto visual claro. Cuando abres una consulta formateada, tu vista encuentra inmediatamente cada cláusula porque todas comienzan en el margen izquierdo (o en un nivel de sangría consistente).

Listas de Columnas y Condiciones con Sangría

Los nombres de columna en la lista SELECT y las condiciones en WHEREtienen sangría de cuatro espacios (o una tabulación). Cada AND y ORen una cláusula WHERE comienza en su propia línea al mismo nivel de sangría que la primera condición, lo que hace trivial añadir, eliminar o comentar condiciones individuales:

WHERE u.created_at >= '2024-01-01'
  AND u.status = 'active'
  AND u.country IN ('US', 'CA', 'GB')

Posición de la Coma: Dos Escuelas de Pensamiento

El debate sobre la posición de la coma en SQL es similar al debate sobre la coma final en JavaScript. Hay dos estilos legítimos:

• Comas finales (coma al final de cada línea): el estilo más común, coincide con la forma en que la mayoría de los desarrolladores escriben listas en otros lenguajes. La desventaja es que comentar el último elemento requiere también eliminar su coma final del elemento anterior.
• Coma primero (coma al inicio de cada línea después de la primera): facilita comentar cualquier línea individual sin tocar las adyacentes. Favorecido por equipos que modifican frecuentemente las listas de columnas durante el desarrollo.

Ambos son válidos. Elige uno y úsalo de forma consistente dentro de un proyecto. El Formateador SQL de BrowseryTools usa comas finales por defecto, lo que se alinea con la mayoría de las guías de estilo y es la convención que la mayoría de los lectores espera.

Alias Alineados con AS

Usa siempre AS explícito para los alias —nunca el estilo implícito sin AS que algunos dialectos permiten (COUNT(o.id) order_count). Cuando aparecen varios alias en una lista SELECT, alinear la palabra clave AS a la misma columna hace que la lista de alias sea más legible:

SELECT
    COUNT(o.id)      AS order_count,
    SUM(o.total)     AS total_spent,
    AVG(o.total)     AS average_order,
    MAX(o.created_at) AS last_order_date

Cómo Leer una Consulta Compleja con Múltiples JOINs

Cuando te encuentras con una consulta con tres, cuatro o cinco JOINs, no empieces desde arriba. Empieza por la cláusula FROM. Eso te indica la tabla primaria, el ancla de la consulta. Cada JOIN posterior añade otra tabla al conjunto de resultados, y la condición ON te dice cómo se relacionan las filas de esa tabla con las ya acumuladas. Solo después de entender el modelo de datos desde FROM y JOIN debes volver a SELECT para ver qué columnas se devuelven, luegoWHERE para el filtrado y GROUP BY para la agregación.

Orden de lectura para cualquier consulta SELECT: FROM → JOIN(s) → WHERE → GROUP BY → HAVING → SELECT → ORDER BY → LIMIT. Esto corresponde al orden en que el motor de base de datos procesa realmente las cláusulas y a cómo debes razonar sobre los datos que fluyen por cada paso.

Formato de Subconsultas

Las subconsultas —consultas anidadas dentro de otra consulta— merecen su propio nivel de sangría. Cada nivel de anidamiento añade un nivel de sangría, por lo que la estructura permanece clara incluso con dos o tres niveles de profundidad:

SELECT
    u.id,
    u.name,
    u.email
FROM users AS u
WHERE u.id IN (
    SELECT DISTINCT o.user_id
    FROM orders AS o
    WHERE o.total > 500
      AND o.created_at >= '2024-01-01'
)
ORDER BY u.name;

La consulta interna es claramente subordinada a la externa. El paréntesis de cierre está alineado con la palabra clave (WHERE) que introdujo la subconsulta. Para subconsultas profundamente anidadas o complejas, las CTE (Common Table Expressions) son casi siempre preferibles porque pueden nombrarse y colocarse al principio de la consulta donde son fáciles de leer.

Patrones de Consulta Comunes y Sus Formas Formateadas

INSERT INTO ... SELECT

INSERT INTO order_archive (
    id,
    user_id,
    total,
    created_at
)
SELECT
    id,
    user_id,
    total,
    created_at
FROM orders
WHERE created_at < '2023-01-01';

UPDATE con JOIN (sintaxis MySQL / SQL Server)

UPDATE users AS u
JOIN subscriptions AS s
    ON u.id = s.user_id
SET u.plan = s.plan_name,
    u.plan_updated_at = NOW()
WHERE s.status = 'active'
  AND s.updated_at >= '2024-01-01';

Consulta WITH (CTE)

Las Common Table Expressions son la herramienta de formato más potente en SQL. Permiten asignar nombres a conjuntos de resultados intermedios, convirtiendo una consulta profundamente anidada en una serie de pasos con nombres claros:

WITH active_users AS (
    SELECT id, name, email
    FROM users
    WHERE status = 'active'
      AND created_at >= '2024-01-01'
),
user_orders AS (
    SELECT
        user_id,
        COUNT(id)  AS order_count,
        SUM(total) AS total_spent
    FROM orders
    GROUP BY user_id
)
SELECT
    au.id,
    au.name,
    au.email,
    uo.order_count,
    uo.total_spent
FROM active_users AS au
LEFT JOIN user_orders AS uo
    ON au.id = uo.user_id
ORDER BY uo.total_spent DESC
LIMIT 20;

Por Qué el Formato Importa para la Revisión de Rendimiento

El formato no es solo cuestión de legibilidad para humanos —también hace visibles los problemas de rendimiento. Una vez que una consulta está bien estructurada, varias clases de problemas se vuelven fáciles de detectar:

• Índices faltantes. Una cláusula WHERE formateada con todas las condiciones en sus propias líneas hace que sea sencillo verificar que cada columna de condición tiene un índice. Sin formato, las condiciones enterradas en una sola línea son fáciles de pasar por alto.
• Productos cartesianos. Un JOIN sin una cláusula ON (o con una condición siempre verdadera) produce un cross-join que multiplica los recuentos de filas. Cuando cada JOIN está en su propia línea con su condición ONsangrada debajo, una condición faltante es inmediatamente obvia.
• Patrones de consulta N+1. Ver una consulta que selecciona una lista de IDs en una subconsulta y luego hace un join de vuelta a la misma tabla es una señal de que la consulta podría reescribirse con un join directo —eliminando el N+1 a nivel SQL en lugar de en el código de la aplicación.
• Funciones sobre columnas indexadas. WHERE DATE(created_at) = '2024-01-01' impide que la base de datos use un índice sobre created_at. En una consulta formateada este patrón resalta; en una de una sola línea es invisible.

Dialectos SQL: Diferencias de Sintaxis a Conocer

SQL es un estándar (ISO/IEC 9075), pero cada base de datos importante lo extiende con sintaxis específica del dialecto. Esto es lo que importa para el formato:

PostgreSQL: Comillas Dobles y Sensibilidad a Mayúsculas

En PostgreSQL, los identificadores sin comillas se convierten a minúsculas. Si creaste una tabla como CREATE TABLE "UserProfiles" (con comillas dobles), debes referenciarla siempre como "UserProfiles" con comillas. Sin comillas, PostgreSQL busca userprofiles y falla. Esto es una fuente común de confusión al migrar desde MySQL o cuando los ORMs generan esquemas con nombres mixtos.

MySQL: Comillas con Acento Grave

MySQL usa acentos graves para citar identificadores, no comillas dobles (aunque MySQL en modo ANSI_QUOTES acepta comillas dobles). Verás acentos graves en el DDL generado por MySQL y en consultas exportadas por herramientas como phpMyAdmin. El Formateador SQL maneja identificadores con acento grave y los preserva para que la salida siga siendo válida para tu base de datos específica.

Cómo Usar el Formateador SQL de BrowseryTools

Usar el formateador toma tres pasos:

• Pega tu consulta. Copia el SQL en bruto de tu archivo de registro, salida de ORM o editor y pégalo en el área de entrada. El formateador acepta cualquier cantidad de SQL —sentencias individuales, múltiples sentencias o scripts completos.
• Haz clic en Formatear. El formateador aplica palabras clave en mayúsculas, separación de cláusulas, sangría y espaciado consistente. El resultado aparece en el panel de salida al instante —sin solicitud de red ni demora.
• Copia el resultado. Usa el botón Copiar para poner el SQL formateado en tu portapapeles, listo para pegar en tu editor, tu cliente de base de datos o tu PR.

Como el formateador se ejecuta completamente en tu navegador, puedes pegar con seguridad consultas que contengan datos sensibles —nombres de tablas de producción, IDs de clientes, detalles internos del esquema— sin que nada salga de tu máquina. No hay backend que registre tus consultas.

Formatea Tus Consultas SQL Ahora

Ya sea que estés desenredando un monstruo generado por un ORM, revisando el pull request de un colega, depurando una consulta lenta o simplemente intentando entender lo que hace una respuesta de Stack Overflow —el SQL formateado hace que cada una de estas tareas sea más rápida y menos propensa a errores. El buen formato es la optimización de rendimiento más barata que puedes hacer antes de recurrir a EXPLAIN.