Dlaczego importowanie pliku .sql o pojemności 12 GB zajmuje więcej niż 36 godzin?

Czekałem teraz 36 godzin na zaimportowanie pliku .sql o pojemności 12 GB za pomocą prostego type site.sql | mysqlpolecenia. Widzę, że ibdata1wciąż rośnie, obecnie prawie 40 GB.

Biorąc pod uwagę, że wyzwalacze i procedury przechowywane są na końcu .sql, myślę tylko, że MySQL powinien dodawać dane i indeksy kluczy.

Site.sql został wygenerowany przy użyciu tego polecenia z innego serwera:

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

Co trwa tak długo?

mysql mysql-5 mariadb

— servermanfail
źródło

ile procesora bierze mysql? Jeśli jest to niska wartość, prawdopodobnie oznacza to, że masz ograniczony dysk

— Derek Downey

Pliki .sql naprawdę nie są tak szybkie do zaimportowania ... tak naprawdę szybciej jest zrzucić do tabulatora lub CSV, a następnie zbudować pustą bazę danych i użyć LOAD DATA INFILE. Ponadto, gdy przenosisz całą bazę danych, zobacz moją odpowiedź dotyczącą: przenoszenia baz danych między serwerami, jeśli pozostajesz w tej samej głównej wersji. (szczególnie jeśli musisz przerwać i zrestartować)

— Joe

Odpowiedzi:

Spróbuj tego:

$ ps -ef|grep [m]ysql

Następnie zidentyfikuj identyfikator procesu

$ strace -cp <pid>

Pozostaw to na 10 sekund lub minutę ^C. To powie ci, gdzie proces spędza czas, np. Może po prostu czekać na dysk, jeśli widzisz readi writedominujesz.

— Gajusz
źródło

+1, ponieważ właśnie nauczyłem się nowego polecenia (strace): P Edycja: bzdury, domyślnie niedostępne na moim komputerze Mac.

— Derek Downey,

To fantastyczne narzędzie wraz z gdb. Nie mówię już ludziom, że ich aplikacja się zawiesiła; Mówię im dokładnie, na czym jest przyczepiony lub obraca się, lub z rdzenia powiedz im wiersz kodu i nazwę pliku źródłowego. Jeszcze mocniejszy jest dtrace.

— Gajusz

Strace to Linux - ekwiwalent Solaris to kratownica. Dtrace jest dostępny na komputerze Mac.

— Gajusz

tak jest. zamierzam przeczytać o tym teraz.

— Derek Downey

Uwaga: fajne polecenie do poznania, ale bądź ostrożny, to polecenie rozbiło moją instancję MySQL. Nie wiem dlaczego. Przed awarią MySQL serwer przestał reagować na kilka minut.

— dabest1

Czy masz jakieś tabele InnoDB z kluczem podstawowym?

zawierający wiele kolumn?
mając szeroki VARCHAR?
i wiele indeksów nie unikatowych?
jeden lub więcej nie unikatowych indeksów z szerokim kluczem?

Każdy z tych warunków może prawdopodobnie spowodować, że duże węzły BTREE w indeksach będą miały bardzo mało liści w każdym węźle BTREE. Klucz klastra w kluczu podstawowym jest także dołączany do każdego wpisu klucza nie unikalnego w kluczach nieklastrowanych.

Kolejna uwaga: czy suma stron danych InnoDB jest znacznie mniejsza niż stron indeksu InnoDB?

Możesz to sprawdzić za pomocą tego zapytania (w MB):

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

Dodatkowe uwagi: Czy masz włączone rejestrowanie binarne na ładowanym serwerze DB? Jeśli tak, zrób to na ładowanym serwerze:

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

Mam nadzieję, że to pomoże !!!

— RolandoMySQLDBA
źródło

Czy jesteś pewien, że tabele, w których czytasz, nie zawierają wyzwalaczy, indeksów i ograniczeń? Na jakim sprzęcie i systemie operacyjnym pracujesz? Jak skonfigurowana jest Twoja pamięć?

Jestem bardziej zaznajomiony z oracle, ale importowanie 12G do tabel bez wyzwalaczy, indeksów i ograniczeń powinno z łatwością iść z 200GB / h. Jeden pojedynczy wyzwalacz może przekształcić proces w ślimaka, w zależności od tego, co to powoduje ...

mam nadzieję, że to pomoże

— ik_zelf
źródło