O que é um arquivo SQL?

SQL é um formato de texto puro que abre em qualquer editor. Ele é usado para mover dados entre programas e o arquivamento.

A extensão é .sql e o nome por extenso é SQL Insert Statements. Os dois importam menos do que aquilo que o arquivo consegue carregar, e é disso que trata o resto desta página.

Ele remonta a 1986. A especificação é ISO/IEC 9075.

A um formato que se manteve legível por tanto tempo dá para confiar algo que você quer de volta daqui a dez anos.

Ela está publicada por inteiro, então dá para implementá-la a partir do documento em vez de por observação — é por isso que o formato aparece em tantos programas e por isso que arquivos escritos há vinte anos ainda abrem. Especificação publicada não é o mesmo que livre de royalties: quando o formato embrulha um codec, o licenciamento das patentes é uma questão à parte, que a norma não resolve.

SQL tem sintaxe de comentário — essa é a diferença entre um arquivo que uma pessoa mantém e um que um programa escreve. Os comentários são a primeira coisa perdida na conversão para um formato que não os tem, e nada avisa.

PostgreSQL, MySQL e DBeaver leem esse formato, e a maioria dos programas do mesmo tipo também.

Quando um arquivo não abre, o formato raramente é o problema — mais comum é o programa ser mais antigo que ele. Converter para algo mais antigo é o caminho confiável, e é para isso que serve o resto deste site.

Nenhum navegador lê o formato.

Esse é de longe o motivo mais comum para convertê-lo: não que o formato seja ruim, mas que o lugar onde você quer mostrar o arquivo não consegue lê-lo.

SQL foi feito para ser aberto e alterado. Mantenha o arquivo nesse formato enquanto o trabalho estiver em andamento e exporte a partir dele sempre que precisar de uma cópia pronta.

SQL é uma linguagem de consulta padronizada desde 1986. Um arquivo .sql é um arquivo de texto com instruções escritas nele, e isso é o formato inteiro — não há cabeçalho, não há estrutura, não há como saber pela extensão o que um arquivo específico faz. Pode criar tabelas, inserir um milhão de linhas, alterar um esquema, ou simplesmente guardar três consultas que alguém quis manter.

Na prática, os que circulam se dividem em dois grupos. Um dump é um banco ou uma tabela escrita como instruções que a recriam em outro lugar. Uma migração é um script que muda um esquema de forma controlada. Os dois são texto, os dois abrem em qualquer editor, e confundir os dois é como um script pensado para adicionar uma coluna acaba apagando uma tabela.

Geralmente três coisas em sequência. Uma instrução que apaga a tabela se ela já existir, motivo de rodar um dump contra um banco em produção não ser um ato reversível. Uma instrução CREATE TABLE definindo as colunas e seus tipos. Depois as linhas, como instruções INSERT — às vezes uma por linha, às vezes algumas centenas agrupadas numa instrução só, o que carrega muito mais rápido e fica bem mais difícil de ler.

Ao redor disso, um dump de verdade acrescenta manutenção: declarações de conjunto de caracteres, ajustes que suspendem a reconstrução de índices enquanto o dado carrega, e um envoltório de transação para que uma falha no meio do caminho não deixe nada pela metade. Essa manutenção é específica de cada banco, e é o principal motivo de um dump de um banco não carregar em outro.

O padrão especifica um núcleo, e cada banco estende esse núcleo. A citação de identificadores difere — crase no MySQL, aspas duplas no PostgreSQL, colchetes no SQL Server. Chaves com incremento automático são escritas de três jeitos diferentes. Funções de data, funções de texto, tratamento de booleano e os próprios nomes de tipo divergem.

Então um dump de MySQL não carrega no PostgreSQL, e o erro que ele produz costuma ser uma reclamação de sintaxe na linha quatro em vez de qualquer coisa que explique o motivo. Converter entre dialetos é trabalho de verdade e majoritariamente mecânico; se você está movendo dado em vez de esquema, passar por CSV costuma ser mais rápido e mais confiável do que traduzir o SQL.

Na linha de comando cada banco tem seu próprio cliente e a chamada é curta: psql para PostgreSQL, o cliente mysql para MySQL e MariaDB, sqlite3 para SQLite, todos aceitando o arquivo como entrada. É de longe a rota mais rápida para um dump grande — uma ferramenta gráfica que carrega o arquivo inteiro na memória primeiro vai sofrer com qualquer coisa acima de algumas centenas de megabytes.

Duas coisas a fazer antes de rodar. Leia o início do arquivo para ver se ele apaga alguma coisa. E crie o banco de destino primeiro se o dump não o criar sozinho, porque um dump escrito para um nome de banco não vai inventar outro silenciosamente.

Geralmente um de quatro motivos. Um limite de tamanho de pacote ou de instrução, atingido por um INSERT em lote com vários milhares de linhas — limite do servidor, não do arquivo. Um timeout num cliente gráfico que não tem equivalente na linha de comando. Uma incompatibilidade de conjunto de caracteres, que aparece como texto corrompido em vez de erro e vale pegar cedo. Ou uma restrição de chave estrangeira rejeitando linhas que chegam antes da tabela que referenciam.

Esse último é o mais comum e o menos óbvio. Dumps geralmente lidam com isso desativando a verificação de restrições durante o carregamento, e um dump editado à mão — algumas tabelas retiradas de um arquivo maior — perde essa proteção. Carregar na ordem de dependência, ou restaurar o envoltório de transação, resolve.

Um dump serve para recriar um banco. Se o que você quer é o dado — analisar, carregar numa planilha, entregar a alguém que não roda banco de dados — CSV é o recipiente melhor, e Parquet é ainda melhor para qualquer coisa grande o bastante para a diferença aparecer.

O caminho inverso também vale conhecer. Transformar uma planilha em instruções INSERT é o jeito padrão de colocar uma tabela num banco quando você não tem conexão direta com ele, situação comum em hospedagem gerenciada: nenhuma porta aberta, mas um console de consulta que roda de bom grado um arquivo colado nele.

É texto, então qualquer editor abre. Um editor que entende sintaxe SQL vale a pena para qualquer coisa que você pretende executar, porque colore as instruções e mostra uma aspa desbalanceada antes de o banco encontrá-la.

Um dump pode ser muito grande, e o jeito sensato de inspecionar um de vários gigabytes é olhar as primeiras e as últimas dezenas de linhas em vez de abrir o arquivo inteiro. As primeiras linhas dizem o dialeto, o conjunto de caracteres e se algo é apagado; as últimas dizem se o dump terminou, a coisa mais útil de saber sobre um arquivo que alguém te mandou.