імпорт mysql звалить неймовірно повільно на машині мого розробника

У мене є дамп SQL, він досить великий (411 Мб), а імпортувати на сервер А потрібно 10 хвилин, той самий імпорт на моїй робочій станції В має оцінку (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 статистика була ще гіршою.

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

Велике запитання: як ефективність може бути повільнішою? Я не можу так працювати :-(

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

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

iostat -xm 5

сервер 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

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

сервер A:

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 через twitter)

Доповнюючи те, що я бачу вище ... Мій файл дампа вже автоматично генерується чимось на зразок:

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команда не зливала рядки між файлами.

Імпорт працює нормально, я не перевіряв, чи дійсно він швидший через це вдосконалення речі для ввімкнення та вимкнення / автоматичного введення в дію, але якщо це робить швидше, то ці додаткові кроки полегшують роботу.

Я також спробував --compress, SET autocommit=0;і вони допомогли невеликій кількості, проте ...

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

Я використовую mysqlSSL через WAN. Віддалена база даних MySQL розміщується на Amazon.

З 9 стовпцями та 2100 рядками:

• 2100 окремих INSERTтверджень: 82с
• 2 консолідовані INSERTзвіти: <1с

З 7 стовпцями та 42 000 рядків:

• 42 000 окремих INSERTтверджень: 1740
• 42 консолідований INSERTвиклад: 105с

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

Примітка. Це також зменшує .sqlдамп-файл на більш ніж 60% у моїх тестах, тому це також заощадить на i / o.

Попередження: Існують фізичні обмеження щодо цієї методикиmysql для та для тих, хто потребує переносимості ... Схоже, SQL Server обмежений лише 1000 рядками одночасно.

Тим не менш, якщо робити 1000 рядків одночасно на 42 000 рядків, це все ще приносить 1 577% покращення!