Exportar solo el esquema (estructura) de un volcado SQL

Tres situaciones aparecen una y otra vez:

• Montar un esquema para staging o CI: quieres la estructura de tablas vacía para que las pruebas se ejecuten contra columnas, índices y restricciones reales, pero desde luego no quieres enviar gigabytes de filas de producción a un entorno desechable.
• Solo datos semilla: el esquema ya existe en la base de datos de destino y solo necesitas las filas INSERT para poblarlo, sin sentencias CREATE que colisionen con lo que hay.
• Deshacerte del ruido: el volcado está inflado por tablas logs, sessions, audit_trail o cache con decenas de millones de filas que nunca quieres importar.

Por qué mysqldump --no-data no basta

El consejo clásico es mysqldump --no-data (solo estructura) o mysqldump --no-create-info (solo datos). Ambos son flags de exportación: cambian lo que contiene un volcado nuevo de una base de datos en ejecución. No hacen nada por un volcado que ya tienes en el disco como archivo .sql.

En la práctica, el archivo suele llegar de otra persona, de un trabajo de copia de seguridad o de un servidor al que ya no tienes acceso en vivo. No puedes volver a ejecutar mysqldump contra una base de datos inalcanzable: las credenciales ya no están, el servidor está desmantelado o el archivo es simplemente todo lo que te entregaron. En ese punto los flags son inútiles y te toca editar el propio archivo.

La vía manual

El movimiento obvio es eliminar líneas con grep o sed. Para conservar la estructura y descartar los datos:

# conserva todo excepto las filas INSERT
grep -v '^INSERT INTO' dump.sql > schema.sql

# o conserva solo las filas INSERT para un archivo de solo datos
grep '^INSERT INTO' dump.sql > data.sql

Esto parece bien en un volcado pequeño y ordenado, y luego se rompe en uno real:

• INSERT multilínea. Un solo INSERT INTO … VALUES puede abarcar miles de líneas. grep coincide con la primera línea y deja el resto de los valores huérfanos, produciendo un archivo roto.
• Inserts extendidos. mysqldump agrupa muchas filas en una sola sentencia gigante. Los filtros por línea no pueden saber dónde termina esa sentencia.
• Comentarios y bloques. Los bloques condicionales /*! … */, LOCK TABLES y los comentarios -- se intercalan con los datos, así que un filtro ingenuo o bien conserva basura o corta algo que la importación necesita.
• Solo datos es peor. Un simple grep '^INSERT' descarta las sentencias SET y LOCK de las que dependen las filas, y cualquier INSERT que no empiece exactamente en la columna cero desaparece silenciosamente.

Acabas depurando tu propio filtro en lugar de obtener tu esquema.

Solo estructura o solo datos con DumpCleaner

DumpCleaner entiende las sentencias SQL en lugar de coincidir líneas, así que separa la estructura de los datos de forma fiable, en archivos de cualquier tamaño:

1. Arrastra tu volcado .sql a DumpCleaner (MySQL, MariaDB o PostgreSQL). Parsea el archivo en streaming, así que un volcado de varios gigabytes se carga con memoria constante.
2. Activa o desactiva los tipos de sentencia que quieras: CREATE TABLE, CREATE INDEX, INSERT INTO, ALTER, DROP, LOCK, SET. Desmarca INSERT INTO y obtienes solo la estructura; desmarca CREATE TABLE / CREATE INDEX y obtienes solo los datos.
3. O elige un preset —Solo estructura o Solo datos— para ajustar todos los conmutadores de una vez y luego refinar por tabla si quieres.
4. Exporta. Obtienes un archivo de esquema ligero para staging o CI, o un volcado limpio de solo datos para poblar.

Como el filtro es consciente de las sentencias, un INSERT extendido multilínea se conserva o se descarta como un todo, nunca cortado por la mitad.

La verdadera potencia está en que el filtrado funciona por tipo de sentencia y por tabla, y ambos se combinan. Puedes conservar la estructura de todas las tablas pero incluir datos INSERT solo para las tres tablas que realmente necesitas, dejando la tabla logs de 89 millones de filas como un cascarón vacío. Eso es algo que ningún flag --no-data puede expresar.

Preguntas frecuentes