La recréation de la base de données MySQL à l'aide de "mysql mydb < mydb.sql" est vraiment lente lorsque la table comporte des dizaines de millions d'enregistrements. Comment l'améliorer

Question

Il semble qu'une base de données MySQL dont la table contient des dizaines de millions d'enregistrements obtiendra un gros INSERT INTO lorsque les éléments suivants

mysqldump some_db > some_db.sql

est fait pour sauvegarder la base de données. (est-ce 1 instruction d'insertion qui gère todo les dossiers ?)

Ainsi, lors de la reconstruction de la BD en utilisant

mysql some_db < some_db.sql

alors le CPU est à peine occupé (environ 1,8% d'utilisation par le processus mysql... je ne vois pas non plus de mysqld ?) et le disque dur ne semble pas non plus être trop occupé...

La dernière fois, le processus de restauration a pris 5 heures. Y a-t-il un moyen de le rendre plus rapide ? Par exemple, lorsque vous faites mysqldump peut-elle briser la INSERT en des phrases plus courtes, de sorte que le mysql n'a pas besoin d'analyser la ligne si durement lors de la restauration de la BD ?

Answer 1

Si quelque chose utilise du temps, ce sera mysqld, c'est ce qui fait réellement tout le travail. Si vous vous connectez à un serveur mysql distant, mysqld sera sur cette machine, pas sur votre machine locale.

Le moyen le plus direct d'accélérer le processus serait de supprimer toutes les clés et tous les index de la table, puis de les créer une fois les données chargées. Maintenir tout à jour à travers autant d'insertions peut être très éprouvant pour un serveur, et vous aurez probablement des index fragmentés de toute façon. Vous pouvez vous attendre à ce que la création des index à la fin des insertions prenne un certain temps, mais ce ne sera pas aussi difficile que de les maintenir tous à jour pendant que les insertions ont lieu.

Une meilleure solution serait d'arrêter d'utiliser mysqldump pour cette table et de passer à l'utilisation de LOAD DATA INFILE (avec la correspondance SELECT ... INTO OUTFILE pour la création de la décharge).

Votre meilleure chance serait de copier les fichiers de la base de données au lieu d'essayer de faire une sauvegarde et une restauration. Je pense que cela ne fonctionne toujours qu'avec les bases de données MyISAM et non InnoDB, mais quelqu'un d'autre peut me corriger si les choses ont changé récemment.