mysql dump import incroyablement lent sur la machine de mon développeur

J'ai un vidage SQL, c'est assez gros (411 Mo) et il a fallu 10 minutes pour importer sur le serveur A, la même importation sur mon poste de travail B a une estimation (pipeviewer) de 8 heures pour importer (il a importé 31 Mo en 40 minutes ) C'est donc un facteur 53 plus lent.

Les spécifications:

Server A:
   MySQL Version: 5.5.30-1.1 (Debian)
   2 GB RAM
   1 core QEMU Virtual CPU version 1.0 - cpu MHz: 3400.020

Workstation B: 
   MySQL Version: 5.5.41-MariaDB-1ubuntu0.14.04.1
   14 GB RAM
   4 cores Intel(R) Core(TM) i5-2400 CPU @ 3.10GHz - cpu MHz: 1600.000

La configuration mysql / maria est la configuration de base.

Hier, je suis passé à MariaDB sur mon poste de travail - mais avant MariaDB, les statistiques étaient encore pires.

J'ai déjà supprimé toutes les bases de données sur mon poste de travail - aucune différence.

La grande question est: comment les performances peuvent-elles être plus lentes de 53? Je ne peux pas travailler comme ça :-(

Ma commande d'importation:

pv sql/master.sql | mysql -h'localhost' -u'root' -p'root' 'master'

iostat -xm 5

serveur A:

avg-cpu:  %user   %nice %system %iowait  %steal   %idle
      17,43    0,00   30,28   51,85    0,00    0,44

Device:         rrqm/s   wrqm/s     r/s     w/s    rMB/s    wMB/s avgrq-sz avgqu-sz   await r_await w_await  svctm  %util
sda               0,00   254,03    0,00 1305,45     0,00     6,09     9,56     0,78    0,60    0,00    0,60   0,57  74,25

poste de travail B:

avg-cpu:  %user   %nice %system %iowait  %steal   %idle
       7,32    0,00    3,22    5,03    0,00   84,42

Device:         rrqm/s   wrqm/s     r/s     w/s    rMB/s    wMB/s avgrq-sz avgqu-sz   await r_await w_await  svctm  %util
sda               0,00     1,40    0,80  172,40     0,00     0,56     6,72     1,17    6,75   12,00    6,72   5,40  93,52

dd if=/dev/zero of=tempfile bs=1M count=1024 conv=fdatasync,notrunc

serveur A:

1073741824 bytes (1,1 GB) copied, 18,6947 s, 57,4 MB/s

poste de travail B:

1073741824 bytes (1,1 GB) copied, 8,95646 s, 120 MB/s

Cette réponse a beaucoup accéléré tout:

/programming//a/2167641/292408

Je, simplement

SET autocommit=0;
SET unique_checks=0;
SET foreign_key_checks=0;

au début, et

COMMIT;
SET unique_checks=1;
SET foreign_key_checks=1;

à la fin.

Maintenant, cela a pris 3 minutes.

(Gracieuseté de @andreasemer via twitter)

Complétant ce que je vois ci-dessus ... J'ai mon fichier de vidage déjà généré automatiquement par quelque chose comme:

mysqldump my_db > db-dump-file.sql

Je veux automatiser cette importation, j'ai donc créé deux fichiers sur mon ordinateur appelés default-start-import.sqlet default-end-import.sqlet leur contenu est default-start-import.sql :

SET autocommit=0;

et default-end-import.sql :

COMMIT;
SET autocommit=1;

et le script que je lance est quelque chose comme ça;

cat default-start-import.sql db-dump-file.sql default-end-import.sql | mysql my_other_db

même commande mais plus facile à lire:

cat default-start-import.sql \
    db-dump-file.sql \
    default-end-import.sql \
| mysql my_other_db

Dans ce cas, catest utilisé pour concaténer ces fichiers avant de les envoyer au canal. Je pense qu'il est important que tous les fichiers se terminent par un caractère de nouvelle ligne (une ligne vide à la fin du fichier si elle est vue depuis un éditeur de texte) afin que la catcommande ne fusionne pas les lignes entre les fichiers.

L'importation fonctionne bien, je n'ai pas testé s'il est réellement plus rapide en raison de cette amélioration de la fonction d'activation et de désactivation de l'autocommit, mais si cela accélère les choses, alors ces étapes supplémentaires facilitent les choses.

J'ai essayé --compressaussi bien SET autocommit=0;et ils ont aidé une petite quantité cependant ...

J'ai trouvé que la conversion de plusieurs INSERT INTO ...instructions en une seule grande instruction avec VALUES(...), (...)une vitesse améliorée multiple considérablement.

J'utilise mysqlSSL sur WAN. La base de données MySQL distante est hébergée sur Amazon.

Avec 9 colonnes et 2100 lignes:

• 2100 INSERTrelevés séparés : 82s
• 2 états INSERTconsolidés: <1s

Avec 7 colonnes et 42 000 lignes:

• 42 000 INSERTrelevés séparés : 1 740
• 42 INSERTétat consolidé : 105s

Ainsi, en fonction de l'outil générant le vidage de la base de données (ou plus précisément du format des INSERTinstructions), la vitesse peut être influencée.

Remarque: Cela diminue également le .sqlfichier de vidage de plus de 60% dans mes tests, donc cela économisera également sur les E / S.

Avertissement: il existe des limites physiques à cette technique avecmysql et pour ceux qui ont besoin de portabilité ... SQL Server semble être limité à seulement 1 000 lignes à la fois.

Pourtant, faire 1 000 lignes à la fois pour 42 000 lignes donne toujours une amélioration de 1 657%!