MySQL ALTER TABLE na bardzo dużym stole - czy można go bezpiecznie uruchomić?

Question

Mam bazę danych MySQL z tabelą MyISAM z 4 milionami wierszy. Aktualizuję tę tabelę raz w tygodniu, używając około 2000 nowych wierszy. Po aktualizacji zmieniam tabelę tak:

ALTER TABLE x ORDER BY PK DESC 

Zamawiam tabelę według klucza podstawowego w kolejności malejącej. To nie sprawiło mi żadnych problemów na moim komputerze programistycznym (Windows z 3GB pamięci). Trzy razy próbowałem go z powodzeniem na produkcyjnym serwerze Linux (z 512 MB pamięci RAM - i osiągając wynikowy posortowany stół za około 6 minut za każdym razem), po raz ostatni spróbowałem go, musiałem przerwać zapytanie po około 30 minutach i odbudować baza danych z kopii zapasowej.

Czy serwer 512 MB może poradzić sobie z tą zmianą na tak dużym stole? Czytałem, że tworzona jest tabela tymczasowa do wykonania polecenia ALTER TABLE.

Pytanie: Czy to polecenie zmiany można bezpiecznie uruchomić? Jaki powinien być przewidywany czas na zmianę tabeli?

Answer 1

Prawdopodobnie utworzę zamiast tego Widok, który jest uporządkowany według wartości PK, więc z jednej strony nie trzeba blokować tego wielkiego stołu podczas wykonywania operacji ALTER.

Answer 2

Jak już przeczytałem, zapytanie ALTER TABLE ... ORDER BY ... jest przydatne do poprawy wydajności w niektórych scenariuszach. Jestem zaskoczony, że Indeks PK nie pomaga w tym. Ale od the MySQL docs wydaje się, że InnoDB używa użyć indeksu. Jednak InnoDB jest wolniejszy niż MyISAM. To powiedziawszy, z InnoDB nie musiałbyś ponownie zamawiać stołu, ale straciłbyś niesamowitą prędkość MyISAM. Wciąż może być warta strzału.

Sposób, w jaki wyjaśniasz problemy, wydaje się, że do pamięci zostało włożonych zbyt wiele danych (być może jest nawet zamiana?). Możesz to łatwo sprawdzić, monitorując zużycie pamięci. Trudno powiedzieć, bo nie znam MySQL tak dobrze.

Z drugiej strony, myślę, że twój problem leży w zupełnie innym miejscu: Używasz maszyny, która ma tylko 512 MB pamięci RAM jako serwer bazy danych z tabelą zawierającą więcej niż 4 miliony wierszy ... A ty wykonujesz bardzo ciężka w pamięci operacja na całym stole na tej maszynie. Wydaje się, że 512 Mega nie wystarczy na to.

O wiele bardziej fundamentalny problem, który widzę tutaj: Pracujesz nad rozwojem (i całkiem prawdopodobnym testowaniem) w środowisku, które bardzo różni się od środowiska produkcyjnego. Można się spodziewać rodzaju problemu, który wyjaśniasz. Twoja maszyna programująca ma sześciokrotnie więcej pamięci niż maszyna produkcyjna. Wierzę, że mogę spokojnie powiedzieć, że procesor jest również znacznie szybszy. W takim przypadku sugeruję utworzenie wirtualnej maszyny naśladującej twoją witrynę produkcyjną. W ten sposób możesz łatwo przetestować swój projekt bez zakłócania procesu produkcji.

Answer 3

To, o co prosisz, to odbudowanie całej tabeli i wszystkich jej indeksów; jest to droga operacja, szczególnie jeśli dane nie pasują do pamięci RAM. To się zakończy, ale będzie znacznie wolniej, jeśli dane nie pasują do RAM, szczególnie jeśli masz dużo indeksów.

Pytam o twój osąd, decydując się na uruchomienie maszyny z tak małą pamięcią w produkcji. W każdym razie:

• Czy ta tabela zmian jest naprawdę potrzebna; jakie konkretne zapytanie próbujesz przyspieszyć i czy próbowałeś bez niego?
• Czy zastanawiałeś się nad tym, aby uczynić swoją maszynę programistyczną bardziej podobną do produkcji?Mam na myśli, że używanie dev boxa z MORE memory nigdy nie jest dobrym pomysłem, a używanie innego systemu operacyjnego zdecydowanie nie jest.

Prawdopodobnie istnieje również możliwość dostrojenia się do pomocy; w dużej mierze zależy to od twojego schematu (w szczególności indeksów). Wiersze 4M to niewiele (dla maszyny z normalną ilością pamięci RAM).

Answer 4

Jeśli używasz InnoDB, nie powinieneś jawnie wykonywać ORDER BY w trybie wstawiania lub w czasie zapytania. Zgodnie z MySQL 5.0 instrukcji, InnoDB już domyślnie klucz podstawowy zamawiającego do wyników zapytania:

http://dev.mysql.com/doc/refman/5.0/en/alter-table.html#id4052480

tabel MyISAM wrócić rekordy w kolejności wstawiania domyślnie, zamiast, który może działać jak dobrze, jeśli tylko kiedykolwiek dołączyć do tabeli, a nie za pomocą zapytania UPDATE, aby zmodyfikować wiersze w miejscu.

Answer 5

jest kluczem podstawowym auto_increment? jeśli tak, to robienie ALTER TABLE ... ORDER BY nie poprawi niczego, ponieważ i tak wszystko zostanie wstawione.

(chyba że masz wiele usunięć)