Divisor de SQL: divida e compacte arquivos SQL

Você recebe um .sql.gz que o phpMyAdmin importa diretamente ou vários arquivos .sql, cada um abaixo do seu limite, disponíveis separadamente e em um ZIP. Se quiser, também em .sql.gz e como texto para copiar. community-db.sql com 98 KB vira um .sql.gz de 20 KB; dividido com tamanho-alvo de 40 KB, são 3 partes, cada uma com o cabeçalho do dump, na ordem de importação. A ferramenta ainda mostra o tamanho, as instruções e as tabelas de cada parte.

O phpMyAdmin recebe arquivos pelo PHP, que limita o tamanho dos uploads (upload_max_filesize e post_max_size). Nos nossos servidores de banco de dados, o limite é de 2 MB; o phpMyAdmin mostra isso em Importar como “Tamanho máximo: 2.048 KiB”. O texto que você cola na aba SQL também está sujeito a esse limite. Por isso, a ferramenta tem o modo “Colar no console SQL”: ele considera o tamanho que o navegador realmente envia e cria partes menores conforme necessário.

Muitas vezes, sim. O limite vale para o arquivo enviado, ou seja, o arquivo compactado, e os dumps SQL contêm muito texto repetido. O phpMyAdmin descompacta arquivos .sql.gz durante a importação. O SQL Splitter calcula primeiro o tamanho do .sql.gz, mostra quantas vezes ele é menor e só recomenda dividir o arquivo se ele ainda ultrapassar seu limite após a compactação.

Carregue um arquivo .sql, .sql.gz ou .zip no SQL Splitter, por exemplo, uma exportação do mysqldump, mariadb-dump, phpMyAdmin, HeidiSQL ou Adminer. A divisão ocorre apenas entre instruções completas: a ferramenta reconhece strings com caracteres de escape, comentários, linhas /*!…*/ e blocos DELIMITER de triggers e procedimentos. Um ponto e vírgula dentro deles não divide a instrução. Se um INSERT com muitas linhas for maior que uma parte, ele será dividido entre registros em vários INSERTs com o mesmo cabeçalho. Se um único registro exceder o tamanho desejado, geralmente por causa de uma imagem em uma coluna BLOB, a ferramenta informará o número da instrução, a linha e a tabela. Importe essa parte com HeidiSQL ou o cliente mysql, ou tente enviá-la como .sql.gz.

Importe na ordem numérica, começando pela parte 1, sempre no mesmo banco de dados. A parte 1 geralmente contém as instruções CREATE TABLE; as partes seguintes preenchem as tabelas. Se o dump tiver chaves estrangeiras, cada parte desativa a verificação delas no início e a reativa no final. Se a importação de uma parte falhar, corrija o erro e retome nessa mesma parte. Não importe as partes anteriores novamente, ou você receberá “Table already exists” ou “Duplicate entry”. Se não souber mais o que já foi importado, esvazie o banco de dados (na aba Estrutura do phpMyAdmin, selecione e exclua todas as tabelas) e recomece pela parte 1.

Views, triggers, procedimentos e eventos registram o usuário sob o qual são executados (DEFINER). Se for um usuário do servidor antigo, como root, seu usuário do banco de dados não poderá criá-los. Marque “Remover DEFINER” na ferramenta para que o servidor os crie com seu usuário. No MariaDB, a permissão necessária se chama SET USER. Se o dump vier do MySQL, as linhas SQL_LOG_BIN (permissão BINLOG ADMIN) e GTID_PURGED também podem falhar; para isso, há a opção “Remover linhas de replicação”.

utf8mb4_0900_ai_ci é a collation padrão do MySQL 8. O MariaDB não a reconhece, nem mesmo na versão 11.6, e interrompe o CREATE TABLE com o erro #1273. A correção “Substituir collations do MySQL 8” troca essa e as outras variantes 0900 por utf8mb4_unicode_ci e as variantes que diferenciam maiúsculas de minúsculas por utf8mb4_bin. Ela não altera os comandos INSERT nem seus dados.

Não. Um dump costuma conter dados de clientes e credenciais. Por isso, a ferramenta lê o arquivo apenas no seu navegador, em um Web Worker. Não há upload, armazenamento nem necessidade de conta. Na aba Rede das ferramentas de desenvolvedor, você pode verificar que nenhuma solicitação envia seu arquivo durante a compactação ou divisão.