Estou migrando um banco de dados de DB2 para MySQL. Existem mesas grandes, por isso leva muito tempo. A questão aqui é:
Se houver uma tabela com cerca de 9 milhões de registros com o mecanismo de armazenamento InnoDB.
Qual das próximas abordagens levaria menos tempo?
Crie a tabela sem índices, chaves estrangeiras ou quaisquer restrições. Carregue os dados. Altere a tabela para definir as restrições
Crie a tabela com restrições e carregue os dados.
Em teoria, a carga dos dados em uma tabela indexada é mais lenta do que em uma tabela não indexada. Mas criar um índice e chaves estrangeiras em grandes tabelas leva muito tempo.
Geralmente é melhor carregar uma tabela InnoDB com nada mais que a PRIMARY KEY. Em seguida, faça um ALTER TABLE para adicionar todos os índices e chaves estrangeiras.
Se você não tiver uma CHAVE PRIMÁRIA explícita, isso é ruim. Altere uma chave UNIQUE para PRIMARY, se prático.
Porém, as chaves estrangeiras podem ser um problema devido às dependências.
Plano A: ALTER uma mesa de cada vez, mas em uma ordem que não possa haver problemas de FK.
Plano B: Desabilite os FKs enquanto faz os ALTERs e, em seguida, habilite-os.
No InnoDB, o PK é 'agrupado' com os dados. Portanto, os dados são classificados pelo PK e armazenados no disco nessa ordem. Portanto, é melhor ter o PK definido e fornecer os dados ao carregador na ordem do PK. O PK+Data está em um BTree.
Chaves secundárias (e FKs) envolvem BTrees separados. Construí-los de forma incremental pode levar à debulha no "buffer pool" (consulte innodb_buffer_pool_size). A construção desse índice separadamente pode envolver uma classificação unix - mais eficiente para índices realmente grandes.
Eu chamaria 9 milhões de linhas bastante grandes (90º percentil), mas não enormes.
Outro cuidado: as chaves UNIQUE precisam ser verificadas à medida que são inseridas. Acho que isso implica que você defina as chaves UNIQUE antecipadamente, e não depois.