CodeKivo LogoCodeKivo

Formateador y Minificador SQL

Estandarice la sintaxis de consultas SQL en los principales motores relacionales o comprímalas en una sola línea para código de producción.

Dialecto SQL:
Plantilla de ejemplo:
Código SQL de entrada1 línea • 532 B
1 sentencia detectada
•
SELECT
  u.id,
  u.username,
  u.email,
  COUNT(o.id) AS total_orders,
  COALESCE(SUM(o.total_amount), 0) AS lifetime_spend,
  MAX(o.created_at) AS last_order_date
FROM
  users u
  LEFT JOIN orders o ON u.id = o.user_id
  AND o.status NOT IN ('cancelled', 'refunded')
WHERE
  u.active = 1
  AND u.created_at >= '2024-01-01'
  AND (
    u.country_code IN ('US', 'CA', 'GB')
    OR u.is_vip = TRUE
  )
GROUP BY
  u.id,
  u.username,
  u.email
HAVING
  COUNT(o.id) > 2
  AND COALESCE(SUM(o.total_amount), 0) >= 250.00
ORDER BY
  lifetime_spend DESC,
  u.username ASC
LIMIT
  50
OFFSET
  0;
586 B•32 líneas•14ms
¿Necesita herramientas complementarias de código o texto?
Formateador de Código|Comparador de Texto y Código

Guía de Operación

Paso 1

Cargar Consulta

Pegue el código SQL sin formato o minificado directamente en el editor, o arrastre un archivo con extensión .sql desde su equipo.

Paso 2

Configurar Reglas

Seleccione el dialecto del motor y ajuste el ancho de sangría (2 o 4 espacios, tabuladores), mayúsculas/minúsculas y el estilo de alineación.

Paso 3

Examinar y Exportar

Verifique los ajustes estructurales usando la pestaña de diferencias Diff, luego copie la consulta al portapapeles o descárguela como archivo.

Ejemplos Prácticos de Transformación

1. CTE, Subconsultas y Alineación de Cláusulas JOIN

Entrada Original (CTE en una sola línea)

with regional_stats as (select department_id, avg(salary) as avg_sal from employees where status = 'active' group by department_id) select e.id, e.first_name, e.last_name, e.salary, r.avg_sal from employees e inner join regional_stats r on e.department_id = r.department_id where e.salary > r.avg_sal order by e.salary desc limit 20;

Resultado Formateado (Cláusulas Indentadas)

WITH regional_stats AS (
  SELECT
    department_id,
    avg(salary) AS avg_sal
  FROM
    employees
  WHERE
    status = 'active'
  GROUP BY
    department_id
)
SELECT
  e.id,
  e.first_name,
  e.last_name,
  e.salary,
  r.avg_sal
FROM
  employees e
  INNER JOIN regional_stats r ON e.department_id = r.department_id
WHERE
  e.salary > r.avg_sal
ORDER BY
  e.salary DESC
LIMIT
  20;

2. Supresión de Comentarios y Protección de Hints del Optimizador

Entrada con Comentarios de Línea y Bloque

-- Cargar pedidos activos forzando índice de fecha
/* Auditoría multilínea: verificación de liquidación */
SELECT /*+ INDEX(orders idx_order_date) */
  id,
  customer_id,
  total_amount
FROM
  orders
WHERE
  status = 'completed'
  AND order_date >= '2024-01-01';

Salida Comprimida (Directiva Hint Preservada)

SELECT /*+ INDEX(orders idx_order_date) */ id,customer_id,total_amount FROM orders WHERE status='completed' AND order_date>='2024-01-01';

3. Definición de Esquemas DDL con Restricciones de Columna

Sentencia DDL en Bruto

create table if not exists accounts (id bigint generated always as identity primary key, email varchar(255) not null unique, balance numeric(14,2) default 0.00 check (balance >= 0), created_at timestamp with time zone default current_timestamp);

Definición de Tabla Estructurada

CREATE TABLE IF NOT EXISTS accounts (
  id bigint GENERATED ALWAYS AS IDENTITY PRIMARY KEY,
  email varchar(255) NOT NULL UNIQUE,
  balance numeric(14, 2) DEFAULT 0.00 CHECK (balance >= 0),
  created_at timestamp WITH time zone DEFAULT current_timestamp
);

Reglas de Procesamiento y Referencia de Opciones

ParámetroValores AdmitidosMecanismo y Garantías de Seguridad
Dialecto SQLANSI Estándar / MySQL / PostgreSQL / SQLite / T-SQL / PL/SQL / MariaDB / Snowflake / BigQuery / ClickHouse / Redshift / DuckDBCarga diccionarios de palabras clave específicas, delimitadores de identificadores y delimitadores de fin de sentencia.
Mayúsculas/MinúsculasMAYÚSCULAS / minúsculas / ConservarNormaliza las palabras reservadas de SQL sin alterar nombres de tablas del esquema, alias ni constantes de cadena.
Anchura de Sangría2 espacios / 4 espacios / TabuladorEstablece el nivel de sangría por cada bloque de anidamiento en subconsultas, CTEs y expresiones entre paréntesis.
Estilo de AlineaciónEstándar / Tabular a la izquierda / Tabular a la derechaSitúa las cláusulas principales justificadas a la izquierda o alinea a la derecha las palabras clave formando un margen continuo.
Operadores LógicosAntes (Inicial) / Después (Final)Ubica las conjunciones AND y OR al inicio de cada condición de filtrado o al término de la línea precedente.
Eliminar ComentariosHabilitado (Comprimir)Suprime anotaciones de una sola línea (-- y #) y de bloque (/* */) manteniendo intactos los literales de texto entre comillas.
Conservar Optimizer HintsHabilitado / DeshabilitadoIdentifica directivas que inician con /*+ ... */ y las conserva en la salida comprimida para evitar degradación de planes de ejecución.

Canalización de Tokenización Léxica y Transformación AST

El lenguaje SQL no puede formatearse de manera fiable mediante expresiones regulares. La gramática permite palabras reservadas dentro de cadenas de texto (ej. 'SELECT status FROM logs'), comillas escapadas ('' o \'), delimitadores propios de cada dialecto y paréntesis anidados. Un motor SQL de producción opera en cuatro fases deterministas:

Fase 1

Flujo Léxico

Descompone la secuencia de caracteres en tokens tipados: palabras clave, operadores, identificadores, literales y comentarios. Las cadenas quedan encapsuladas para evitar mutaciones accidentales.

Fase 2

Pila de Ámbitos

Rastrea el anidamiento de paréntesis y expresiones CTE, distinguiendo bloques de subconsulta de argumentos de funciones escalares como COALESCE().

Fase 3

Estructuración

Aplica saltos de línea a cláusulas (SELECT, FROM, WHERE), sangra subárboles dependientes o compacta espacios en blanco según el modo activo.

Fase 4

Serialización

Emite el texto formateado respetando los delimitadores de línea configurados, o concatena los tokens en una cadena mínima preservando los espacios de separación obligatorios.

Matriz Gramatical y Delimitadores entre Dialectos SQL

Los distintos motores de bases de datos aplican normas específicas para delimitadores de identificadores, parámetros y cláusulas exclusivas. La siguiente matriz detalla cómo se gestionan dichas discrepancias:

Dialecto del MotorDelimitador de IdentificadorMarcadores de ParámetrosCláusulas y Características Específicas
SQL Estándar (ANSI)"identificador"?FETCH FIRST n ROWS ONLY, funciones de ventana estándar
MySQL y MariaDB`identificador`?, :paramLIMIT offset, count, ON DUPLICATE KEY UPDATE, comentarios con #
PostgreSQL"identificador"$1, $2, ?RETURNING, ON CONFLICT DO UPDATE, bloques delimitados por dólar ($$body$$)
SQLite`id`, "id", [id]?, ?1, :nombre, @nombre, $nombreSintaxis UPSERT, AUTOINCREMENT, tipado flexible en columnas
SQL Server (T-SQL)[identificador]@param, ?TOP (n), CROSS APPLY, OUTER APPLY, hints de tabla WITH (NOLOCK)
Oracle PL/SQL"identificador":param, :1CONNECT BY, filtrado ROWNUM, hints de optimizador (/*+ ... */)
Snowflake y BigQuery`identificador` / "id"?, @paramCláusula QUALIFY, FLATTEN / UNNEST semiestructurado, tablas con comillas invertidas
ClickHouse`identificador` / "id"? / {param:Type}PREWHERE, FINAL, ARRAY JOIN, configuración de motor ENGINE = MergeTree
Amazon Redshift"identificador"?, $1DISTKEY, SORTKEY, comandos VACUUM, operaciones UNLOAD / COPY hacia data lakes
DuckDB"identificador" / `id`?, $1, $nombreCOLUMNS(*), EXCLUDE, REPLACE, consultas directas sobre ficheros Parquet y CSV

Invariantes de Minificación Segura y Protección de Optimizer Hints

Comprimir sentencias SQL exige cumplir invariantes léxicos estrictos. Suprimir caracteres sin control genera excepciones de ejecución o caídas de rendimiento:

Prevención de Colisión de Tokens

Los espacios entre tokens alfanuméricos contiguos (SELECT id FROM users) no pueden eliminarse sin fundirlos erróneamente en SELECTidFROMusers. Asimismo, operadores aritméticos consecutivos (como restar constantes negativas a - -1) deben conservar separación para evitar que el segundo signo menos se interprete como prefijo de comentario en línea (--).

// Entrada original: WHERE a - -1
// Minificación segura: WHERE a- -1 (SQL Válido)
// Eliminación no segura: WHERE a--1 (Provoca error de comentario)

Preservación de Directivas de Optimización (Hints)

Los optimizadores interpretan comentarios que inician con /*+ (ej. Oracle /*+ INDEX(t idx) */, MySQL /*+ MAX_EXECUTION_TIME(1000) */ o PostgreSQL pg_hint_plan) como instrucciones imperativas. Borrar indiscriminadamente los bloques de comentarios fuerza al planificador a retroceder a escaneos completos de tabla.

// Comentario con directiva del optimizador:
SELECT /*+ LEADING(e d) */ e.name FROM emp e ...
// Conservado en salida: La directiva permanece intacta

Flujos de Trabajo de Ingeniería en Producción

Desofuscación de Consultas de ORMs

Extraiga consultas masivas de una sola línea generadas por Hibernate, Prisma, TypeORM o SQLAlchemy. El formateo desglosa joins anidados, condiciones de filtrado y subconsultas durante investigaciones con EXPLAIN ANALYZE.

Revisión de Migraciones de Base de Datos

Estandarice esquemas de tablas, declaraciones de índices y claves foráneas antes de confirmar scripts en herramientas como Flyway, Liquibase o Sqitch, asegurando historiales de Git diff limpios y legibles.

Optimización de Cargas Útiles y RPC

Comprima sentencias SQL incrustadas en archivos de configuración de microservicios, cargas JSON o llamadas RPC, eliminando bytes innecesarios de espacios en blanco sin alterar la semántica relacional.

Auditoría de Logs de Consultas Lentas

Pegue entradas de registro procedentes de los slow query logs de MySQL, la vista pg_stat_statements de PostgreSQL o AWS CloudWatch Insights para diagnosticar cuellos de botella con rapidez.

Frequently Asked Questions

¿Cómo formatear consultas SQL complejas con subconsultas anidadas y múltiples JOINs?

Pegue la sentencia SQL en el editor y elija la anchura de sangría deseada (2 espacios, 4 espacios o tabulador). El analizador sintáctico evalúa la profundidad de paréntesis y expresiones CTE, desglosando las cláusulas principales (SELECT, FROM, WHERE, GROUP BY, HAVING) en nuevas líneas mientras aplica sangría jerárquica a las subconsultas y condiciones JOIN ON para una lectura clara.

¿La minificación de SQL altera el plan de ejecución, los resultados o el rendimiento del motor de base de datos?

En absoluto. Los motores de bases de datos relacionales (MySQL, PostgreSQL, Oracle, SQL Server) tokenizan las consultas suprimiendo espacios en blanco redundantes y comentarios no operativos antes de generar el plan de ejecución. El SQL comprimido produce resultados idénticos mientras reduce drásticamente el peso de la carga útil a través de sockets de red y llamadas RPC de microservicios.

¿Cómo influye la selección del dialecto en el formateo entre MySQL, PostgreSQL, SQLite y SQL Server?

Cada motor de base de datos sigue especificaciones gramaticales distintas. Seleccionar el dialecto adecuado garantiza que los delimitadores de identificadores específicos (comillas invertidas en MySQL, corchetes en T-SQL, comillas dobles en PostgreSQL), el escape de literales de cadena y las cláusulas especializadas (como QUALIFY, RETURNING o CROSS APPLY) se interpreten y sangren con total exactitud.

¿Admite el formateador consultas parametrizadas y marcadores de posición preparados?

Sí. El motor de formateo reconoce los marcadores de posición posicionales (?, $1, $2) y los parámetros con nombre (:id, @user_id) como identificadores atómicos. Su sintaxis, símbolos de prefijo e índices numéricos se mantienen inalterados tanto en el modo formateado como en el comprimido.

¿Por qué se conservan los hints del optimizador de base de datos al eliminar comentarios durante la compresión?

Los planificadores de consultas interpretan los comentarios estructurados que inician con /*+ (como Oracle /*+ INDEX(...) */, MySQL /*+ MAX_EXECUTION_TIME(...) */ o PostgreSQL pg_hint_plan) como directivas operativas vinculantes. Eliminar indiscriminadamente estos bloques junto con comentarios ordinarios degradaría la optimización forzando lecturas secuenciales completas de tabla (table scans).

¿Cuál es la diferencia técnica entre la sangría estándar y la alineación tabular de palabras clave?

La sangría estándar sitúa las palabras clave principales justificadas a la izquierda y sangra el cuerpo de cada cláusula con respecto a ellas. La alineación tabular alinea a la derecha las palabras clave reservadas (SELECT, FROM, WHERE, ORDER BY) para que la lista de columnas, las tablas y las condiciones coincidan a lo largo de un margen vertical continuo, facilitando la auditoría de consultas complejas.

¿Cómo resalta el visor Diff los cambios entre el código SQL original y el procesado?

La pestaña Diferencias (Diff) aplica el algoritmo LCS (subsecuencia común más larga de Myers) para contrastar línea por línea el código de entrada y la salida procesada. Muestra en verde las líneas o sangrías incorporadas y en rojo los comentarios o espacios descartados, permitiendo verificar cada ajuste sintáctico antes de exportar el script.

¿Por qué no es seguro formatear o comprimir SQL empleando expresiones regulares simples?

El lenguaje SQL es dependiente del contexto: una cadena literal puede albergar palabras clave (por ejemplo, 'SELECT status FROM logs') o comillas escapadas, y pueden existir operadores aritméticos consecutivos (como en a - -1). El reemplazo por expresiones regulares suele confundir signos negativos adyacentes con prefijos de comentarios (--), corrompiendo la validez del script.