mysql dump import невероятно медленно на машине моего разработчика

У меня есть дамп SQL, он довольно большой (411 МБ), и импорт на сервере A занял 10 минут, тот же импорт на моей рабочей станции B имеет оценку (pipeviewer), равную 8 часам (импорт 31 МБ за 40 минут). ) Так что это в 53 раза медленнее.

Спецификации:

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

Конфигурация mysql / maria является стандартной конфигурацией.

Вчера я переключился на MariaDB на своей рабочей станции - но до MariaDB статистика была еще хуже.

Я уже удалил все базы данных на моей рабочей станции - без разницы.

Главный вопрос: как производительность может быть в 53 раза медленнее? Я не могу работать так :-(

Моя команда импорта:

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

iostat -xm 5

сервер А:

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

рабочая станция 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

сервер А:

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

рабочая станция B:

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

Этот ответ ускорил все:

/programming//a/2167641/292408

Я просто

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

в начале и

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

в конце.

Теперь это заняло 3 минуты.

(Предоставлено @andreasemer через твиттер)

В дополнение к тому, что я вижу выше ... Мой файл дампа уже автоматически сгенерирован чем-то вроде:

mysqldump my_db > db-dump-file.sql

Я хочу , чтобы автоматизировать этот импорт , так что я создал два файла в компьютере под названием default-start-import.sqlи default-end-import.sqlи их содержимое по умолчанию пуск-import.sql :

SET autocommit=0;

и default-end-import.sql :

COMMIT;
SET autocommit=1;

и скрипт, который я запускаю, выглядит примерно так;

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

та же команда, но легче читать:

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

В этом случае catиспользуется для объединения этих файлов перед отправкой их в канал. Я думаю, что важно, чтобы все файлы заканчивались символом новой строки (пустой строкой в ​​конце файла, если она видна из текстового редактора), чтобы catкоманда не объединяла строки между файлами.

Импорт работает нормально, я не проверял, действительно ли он быстрее из-за этого усовершенствования в функции enable-and-disable-autocommit, но если это делает вещи быстрее, то эти дополнительные шаги делают вещи проще.

Я пытался --compressтак же, какSET autocommit=0; и они помогли немного, однако ...

Я обнаружил, что преобразование нескольких INSERT INTO ...операторов в один большой оператор с несколькимиVALUES(...), (...) улучшенной скоростью значительно.

я использую mysql по SSL через WAN. Удаленная база данных MySQL размещена на Amazon.

С 9 столбцами и 2100 строками:

• 2100 отдельных INSERT заявлений: 82 с
• 2 консолидированных INSERTотчета: <1 с

С 7 столбцами и 42 000 строк:

• 42 000 отдельных INSERT заявлений: 1 740
• 42 консолидированный INSERTотчет: 105с

Таким образом, в зависимости от инструмента, генерирующего дамп базы данных (или, более конкретно, формат INSERT операторов), скорость может зависеть.

Примечание. Это также уменьшает .sqlразмер файла дампа в моих тестах более чем на 60%, поэтому он также экономит на операциях ввода-вывода.

Предупреждение: у этого методаmysql есть физические ограничения для тех, кому нужна мобильность ... SQL Server , по-видимому, ограничен только 1000 строками одновременно.

Тем не менее, выполнение 1000 строк одновременно для 42 000 строк по-прежнему дает улучшение на 1657%!