Eu experimentei esse conceito um pouco em um trabalho anterior, onde precisávamos de um método rápido de copiar esquemas entre servidores MySQL.

De fato, há uma sobrecarga de desempenho quando você insere em tabelas que possuem índices secundários. As inserções precisam atualizar o índice clusterizado (também conhecido como tabela) e também atualizar os índices secundários. Quanto mais índices uma tabela tiver, mais sobrecarga ela causará nas inserções.

O InnoDB tem um recurso chamado change buffer o que ajuda um pouco adiando as atualizações do índice, mas elas precisam ser mescladas eventualmente.

As inserções em uma tabela sem índices secundários são mais rápidas, portanto, é tentador tentar adiar a criação do índice até que seus dados sejam carregados, conforme você descreve.

O Percona Server, uma ramificação do MySQL, experimentou com um mysqldump --optimize-keys opção. Quando você usa esta opção, ela altera a saída do mysqldump para ter CREATE TABLE sem índices, então INSERT todos os dados, então ALTER TABLE para adicionar os índices após os dados serem carregados. Consulte https://www.percona.com/doc/ percona-server/LATEST/management/innodb_expanded_fast_index_creation.html

Mas, na minha experiência, a melhoria líquida no desempenho foi pequena. Ainda demora um pouco para inserir muitas linhas, mesmo para tabelas sem índices. Em seguida, a restauração precisa executar um ALTER TABLE para construir os índices. Isso demora um pouco para uma mesa grande. Quando você conta o tempo de INSERTs mais o tempo extra para construir índices, é apenas alguns (baixos dígitos) por cento mais rápido do que inserir da maneira tradicional, em uma tabela com índices.

Outro benefício dessa criação de índice de pós-processamento é que os índices são armazenados de forma mais compacta, portanto, se você precisar economizar espaço em disco, esse é um motivo melhor para usar essa técnica.

Achei muito mais benéfico para o desempenho restaurar carregando várias tabelas em paralelo .

• A nova ferramenta MySQL 8.0 mysqlpump suporta dump multithread.
• A ferramenta de código aberto mydumper suporta dump multithread e também possui uma ferramenta de restauração multithread, chamada myloader . A pior desvantagem do mydumper/myloader é que a documentação é praticamente inexistente, então você precisa ser um usuário avançado intrépido para descobrir como executá-lo.

Outra estratégia é usar mysqldump --tab para despejar arquivos CSV em vez de scripts SQL. O carregamento em massa de arquivos CSV é muito mais rápido do que a execução de scripts SQL para restaurar os dados. Bem, ele despeja um arquivo SQL para a definição da tabela e um CSV para os dados a serem importados. Ele cria arquivos separados para cada tabela. Você precisa recriar manualmente as tabelas carregando todos os arquivos SQL (isso é rápido) e depois usar mysqlimport para carregar os arquivos de dados CSV. A ferramenta mysqlimport ainda tem um --use-threads opção de execução paralela.

Teste cuidadosamente com diferentes números de threads paralelos. Minha experiência é que 4 threads é o melhor. Com maior paralelismo, o InnoDB se torna um gargalo. Mas sua experiência pode ser diferente, dependendo da versão do MySQL e da capacidade de desempenho do hardware do seu servidor.

O método de restauração mais rápido de todos é quando você usa uma ferramenta de backup físico, o mais popular é Percona XtraBackup . Isso permite backups rápidos e restaurações ainda mais rápidas. Os arquivos de backup estão literalmente prontos para serem copiados no local e usados ​​como arquivos de tablespace ativos. A desvantagem é que você deve desligar seu MySQL Server para realizar a restauração.