Mengapa mengimpor file .sql 12 GB membutuhkan waktu lebih dari 36 jam?

Saya sudah menunggu selama 36 jam untuk file .sql 12 GB yang akan diimpor dengan sederhana type site.sql | mysql perintah . Saya dapat melihat ibdata1masih tumbuh, saat ini hampir 40 GB.

Mengingat pemicu dan prosedur tersimpan di akhir .sql, saya hanya berpikir MySQL harus menambahkan data dan indeks utama.

Site.sql dibuat menggunakan perintah ini dari server lain:

mysqldump -R -e --databases site --add-drop-database --add-create-database --add-drop-table -C --single-transaction --triggers

Apa yang butuh waktu lama?

mysql mysql-5 mariadb

— kegagalan server
sumber

berapa cpu yang diambil mysql? Jika nilainya rendah, itu mungkin berarti Anda terikat disk

— Derek Downey

file .sql sebenarnya tidak secepat itu untuk diimpor ... sebenarnya lebih cepat untuk dibuang ke tab delim atau CSV, lalu buat database kosong dan gunakan LOAD DATA INFILE. Juga, saat Anda memindahkan seluruh database, lihat jawaban saya: memindahkan database antar server jika Anda tetap berada dalam versi utama yang sama. (terutama jika Anda harus membatalkan & memulai kembali)

— Joe

Jawaban:

Coba ini:

$ ps -ef|grep [m]ysql

Identifikasi id proses kemudian

$ strace -cp <pid>

Biarkan 10 detik atau semenit kemudian ^C . Itu akan memberi tahu Anda di mana proses menghabiskan waktu, misalnya itu bisa saja menunggu disk jika Anda melihat readdan writemendominasi.

— Gayus
sumber

+1 karena saya baru belajar perintah baru (strace): P Edit: well crap, tidak tersedia di mac saya secara default.

— Derek Downey

Ini adalah alat yang fantastis, bersama dengan gdb. Saya tidak memberi tahu orang-orang aplikasi mereka telah digantung lagi; Saya memberi tahu mereka persis apa itu macet atau berputar, atau dari inti beri tahu mereka baris kode dan nama file sumber. Yang lebih kuat lagi adalah dtrace.

— Gayus

Strace adalah Linux - Solaris equiv adalah truss. Dtrace tersedia di Mac.

— Gayus

begitulah. akan pergi membaca sekarang.

— Derek Downey

Hati-hati: Perintah yang bagus untuk diketahui, tapi hati-hati, perintah ini membuat instance MySQL saya mogok. Tidak tahu kenapa Sebelum MySQL mogok, server menjadi tidak responsif selama beberapa menit.

— dabest1

Apakah Anda memiliki tabel InnoDB dengan Kunci Utama

mengandung banyak kolom?
memiliki VARCHAR yang luas?
dan banyak indeks yang tidak unik?
satu atau lebih indeks bukan unik yang memiliki kunci lebar?

Salah satu dari kondisi ini mungkin dapat menyebabkan node BTREE besar dalam indeks Anda memiliki sangat sedikit daun di setiap node BTREE. Kunci kluster di Kunci Utama juga dilampirkan pada setiap entri kunci non-Unik pada kunci yang tidak tercakup.

Pertimbangan lain: Apakah jumlah halaman data InnoDB secara signifikan kurang dari halaman indeks InnoDB?

Anda dapat menemukannya dengan kueri ini (dalam MB):

SELECT SUM(data_length)/POWER(1024,2) InnoDBData,
SUM(index_length)/POWER(1024,2) InnoDBIndexes
FROM information_schema.tables WHERE engine='InnoDB';

Pertimbangan tambahan: Apakah Anda memiliki pencatatan biner di server DB yang Anda muat? Jika ya, lakukan ini di server yang Anda muat:

mysql -h... -u... -p... -A -e"SET sql_log_bin=0; source site.sql"

Saya harap ini membantu !!!

— RolandoMySQLDBA
sumber

Apakah Anda yakin bahwa tabel di mana Anda membaca tanpa pemicu dan indeks dan kendala? Perangkat keras dan OS apa yang Anda jalankan? Bagaimana penyimpanan Anda dikonfigurasi?

Saya lebih akrab dengan oracle tetapi mengimpor 12G di atas meja tanpa pemicu, indeks, dan kendala harus dengan mudah berjalan dengan 200GB / jam. Satu pemicu tunggal dapat membuat proses menjadi siput, tergantung pada apa yang memicu ...

saya harap ini membantu

— ik_zelf
sumber