mysql dökümü ithalat geliştiricimin makinesinde inanılmaz yavaş

Bir SQL dökümü var, oldukça büyük (411 MB) ve sunucu A'ya içe aktarma 10 dakika sürdü, B iş istasyonumdaki aynı içe aktarma işleminin 8 saatlik tahmini (pipeviewer) içe aktarılması (40 dakika içinde 31 MB içe aktarıldı) ) Yani bu faktör 53 daha yavaştır.

Özellikleri:

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 yapılandırması stok yapılandırmasıdır.

Dün iş istasyonumda MariaDB'ye geçtim - ama MariaDB'den önce istatistikler daha da kötüydü.

İş istasyonumdaki tüm veritabanlarını zaten kaldırdım - fark yok.

Büyük soru şu: Performans 53 faktörü nasıl daha yavaş olabilir? Böyle çalışamıyorum :-(

İçe aktarma komutum:

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

iostat -xm 5

A sunucusu:

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

iş istasyonu 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 sunucusu:

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

iş istasyonu B:

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

Bu cevap her şeyi çok hızlandırdı:

/programming//a/2167641/292408

Ben sadece

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

başında ve

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

sonunda.

Şimdi 3 dakika sürdü.

(@Andreasemer'ın izniyle twitter üzerinden)

Yukarıda gördüklerimi tamamlayan ... Döküm dosyası zaten otomatik olarak aşağıdaki gibi bir şey tarafından oluşturulmuş var:

mysqldump my_db > db-dump-file.sql

Ben denilen bilgisayarımda iki dosya oluşturdu yüzden bu ithalat otomatikleştirmek isteyen default-start-import.sqlve default-end-import.sqlve içerikleri olan varsayılan başlatma-import.sql :

SET autocommit=0;

ve default-end-import.sql :

COMMIT;
SET autocommit=1;

ve çalıştırdığım senaryo şöyle;

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

aynı komut ama okunması daha kolay:

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

Bu durumda cat, boruya göndermeden önce bu dosyaları birleştirmek için kullanılır. catKomutun dosyalar arasındaki satırları birleştirmemesi için tüm dosyaların yeni satır karakteriyle bitmesi (bir metin düzenleyiciden görüldüğünde dosyanın sonunda boş bir satır) olması önemlidir .

İçe aktarma iyi çalışıyor, etkinleştirme ve devre dışı bırakma-otomatik tamamlama işlemindeki bu iyileştirme nedeniyle gerçekten daha hızlı olup olmadığını test etmedim, ancak bu işleri daha hızlı hale getirirse, bu ekstra adımlar işleri kolaylaştırır.

Ben denedim --compressyanı sıra SET autocommit=0;ve onlar ancak küçük bir miktar yardım etti ...

Birden çok INSERT INTO ...ifadeyi büyük bir ifadeye dönüştürerek, çok sayıda VALUES(...), (...)geliştirilmiş hızı önemli ölçüde buldum .

mysqlWAN üzerinden SSL üzerinden kullanıyorum . Uzak MySQL veritabanı Amazon'da barındırılmaktadır.

9 sütun ve 2.100 satırla:

• 2.100 ayrı INSERTifade: 82s
• 2 konsolide INSERTifade: <1s

7 sütun ve 42.000 satırla:

• 42.000 ayrı INSERTifade: 1.740'lar
• 42 konsolide INSERTbeyan: 105'ler

Bu nedenle, veritabanı dökümü oluşturan araca (veya daha özel olarak INSERTifadelerin biçimine ) bağlı olarak, hız etkilenebilir.

Not: Bu aynı zamanda .sqltestlerimde döküm dosyasını% 60'ın üzerinde azaltır , bu nedenle i / o'da da tasarruf sağlar.

Uyarı: Bu tekniklemysql ve taşınabilirliğe ihtiyaç duyanlar için fiziksel sınırlamalar vardır ... SQL Server bir seferde yalnızca 1.000 satırla sınırlı görünmektedir .

Yine de, 42.000 satır için bir seferde 1.000 satır yapmak hala% 1,657 iyileşme sağlıyor!