Exportar apenas o esquema (estrutura) de um dump SQL

Três situações surgem repetidamente:

• Montar um esquema para staging ou CI — quer a estrutura de tabelas vazia para que os testes corram contra colunas, índices e restrições reais, mas de todo não quer despejar gigabytes de linhas de produção num ambiente descartável.
• Apenas dados de seed — o esquema já existe na base de dados de destino e só precisa das linhas INSERT para o preencher, sem instruções CREATE que colidam com o que já lá está.
• Livrar-se do ruído — o dump está inchado por tabelas logs, sessions, audit_trail ou cache com dezenas de milhões de linhas que nunca quer importar.

Porque é que o mysqldump --no-data não chega

O conselho clássico é mysqldump --no-data (apenas estrutura) ou mysqldump --no-create-info (apenas dados). Ambos são opções de exportação: mudam o que um dump novo a partir de uma base de dados em execução contém. Não fazem nada por um dump que já tem no disco como ficheiro .sql.

Na prática, o ficheiro chega muitas vezes de outra pessoa, ou de um trabalho de backup, ou de um servidor a que já não tem acesso ativo. Não consegue voltar a correr o mysqldump contra uma base de dados inacessível — as credenciais desapareceram, o servidor foi desativado, ou o ficheiro é simplesmente tudo o que lhe deram. Nesse ponto as opções são inúteis e resta-lhe editar o próprio ficheiro.

A forma manual

O passo óbvio é remover linhas com grep ou sed. Para manter a estrutura e eliminar os dados:

# manter tudo exceto as linhas INSERT
grep -v '^INSERT INTO' dump.sql > schema.sql

# ou manter apenas as linhas INSERT para um ficheiro só de dados
grep '^INSERT INTO' dump.sql > data.sql

Isto parece bem num dump pequeno e arrumado — e depois falha num real:

• INSERTs multilinha. Um único INSERT INTO … VALUES pode estender-se por milhares de linhas. O grep corresponde à primeira linha e deixa o resto dos valores órfãos, produzindo um ficheiro partido.
• Inserts estendidos. O mysqldump agrupa muitas linhas numa só instrução gigante. Os filtros baseados em linhas não conseguem saber onde essa instrução termina.
• Comentários e blocos. Os blocos condicionais /*! … */, o LOCK TABLES e os comentários -- intercalam-se com os dados, por isso um filtro ingénuo ou mantém lixo ou corta algo de que a importação precisa.
• Só os dados é pior. Um grep '^INSERT' puro deita fora as instruções SET e LOCK de que as linhas dependem, e qualquer INSERT que não comece exatamente na coluna zero desaparece em silêncio.

Acaba a depurar o seu próprio filtro em vez de obter o seu esquema.

Apenas estrutura ou apenas dados com o DumpCleaner

O DumpCleaner compreende as instruções SQL em vez de corresponder a linhas, por isso separa a estrutura dos dados de forma fiável — em ficheiros de qualquer tamanho:

1. Arraste o seu dump .sql para o DumpCleaner (MySQL, MariaDB ou PostgreSQL). Faz o parse do ficheiro em streaming, por isso um dump de vários gigabytes carrega com memória constante.
2. Ative os tipos de instrução que quer: CREATE TABLE, CREATE INDEX, INSERT INTO, ALTER, DROP, LOCK, SET. Desmarque INSERT INTO e obtém apenas a estrutura; desmarque CREATE TABLE / CREATE INDEX e obtém apenas os dados.
3. Ou escolha uma predefinição — Apenas estrutura ou Apenas dados — para definir todos os interruptores num só passo e depois afine por tabela, se quiser.
4. Exporte. Obtém um ficheiro de esquema enxuto para staging ou CI, ou um dump limpo só de dados para seeding.

Como o filtro é ciente das instruções, um INSERT estendido multilinha é mantido ou eliminado como um todo — nunca cortado a meio.

O verdadeiro poder é que a filtragem funciona por tipo de instrução e por tabela, e as duas combinam-se. Pode manter a estrutura de todas as tabelas mas incluir dados INSERT apenas para as três tabelas de que precisa mesmo — deixando a tabela logs de 89 milhões de linhas como uma casca vazia. Isso é algo que nenhuma opção --no-data consegue exprimir.

Perguntas frequentes