Chciałbym się odnieść do komentarza umieszczonego pod poprzednim postem przez Marcina. Zacząłem pisać odpowiedź, ale okazało się, że trochę się rozpisałem i dlatego też umieszczam ją jako post a nie komentarz.

Oczywiście, wybór silnika zawsze będzie zależał do administratora. Nie zgodzę się jednak w kwestii istnienia w InnoDB „poważnych” błędów. Marcin wspominał o dwóch z nich. Jak dla mnie, obydwa z nich działają na zasadzie „to nie bug a ficzer”.

Problem ze „zwalnianiem” miejsca na dysku rozwiązać można przy pomocy innodb_file_per_table=1. Owszem, problemem było to, że ustawienie to trzeba było włączyć przed wgraniem danych na serwer. Co więcej, trzeba było w ogóle wiedzieć, że jest taka flaga do ustawienia. Dlatego też, począwszy od MySQL 5.5, czyli obecnej wersji stabilnej, innodb_file_per_table jest włączone domyślnie. Tak więc, jeśli tylko chcemy zwolnić miejsce na dysku, wystarczy w wersji szybkiej (i drastycznej, bo usuwamy wszystkie dane z tabeli) DROP TABLE, w wersji wolniejszej, DELETE FROM table … + ALTER TABLE table ENGINE=InnoDB; Myślę więc, że ten problem można uznać za rozwiązany od dwóch lat (MySQL 5.5 stał się wersją stabilną jakoś w grudniu 2010).

Sprawa z auto_increment, jakkolwiek oczywiście kłopotliwa, z pewnością nie stanowi „poważnego” błędu, który może sprawić że serwer „klęknie”. Co więcej, jak najbardziej da się go obejść w taki, czy inny sposób. Będzie to kosztować trochę czasu programisty, ale to tylko tyle.

W przypadku MyISAM natomiast „błędów” (w cudzysłowiu, bo tak na prawdę to nie błędy, a założenia konstrukcyjne), które mogą spowodować poważne problemy związane z niedostępnością danych jest znacznie więcej. Załóżmy, że wykonujesz operację modyfikowania dużej ilości danych. Jakiś skomplikowany UPDATE. Zapytanie to powoduje, że serwer przestaje wytrzymywać obciążenie. W przypadku InnoDB zabijamy zapytanie. Transakcja jest cofana, wszystko wraca do stanu przed UPDATE. W przypadku MyISAM można co najwyżej trzymać kciuki, żeby serwer wytrzymał. Owszem, zabić je możemy, tylko nie będziemy wiedzieć co dokładnie się zmodyfikowało, a co jeszcze nie. Jasne, zazwyczaj da się do tego jakość dojść, ale zazwyczaj potrzebujemy do tego czasu. Jeśli w efekcie przerwania zapytania rozsypały się dane np. w sklepie internetowym, nie mamy czasu żeby dłubać rekord po rekordzie i ręcznie odtwarzać stan. W efekcie kończy się na przywróceniu ostatniego backupu.

Jeśli do powyższego dorzucimy replikację, to sprawa się jeszcze bardziej pogarsza. Spotkałem się z taką sytuacją, gdzie zapytanie typu UPDATE zostało błędnie napisane. Tabela rzędu kilkuset milionów rekordów, zamiast podzielić ją na części i wykonać x UPDATE, każde np. po milion rekordów, poszło UPDATE na całość. Oczywiście, lag w replikacji skoczył w kosmos, alerty w Nagiosie się odpaliły, smsy zostały wysłane do DBA. Niestety, jako że silnikiem było MyISAM jedyną odpowiedzią było – czekać. Jeśli w takiej sytuacji przerwiemy wykonywanie zapytania na slave, to zazwyczaj jedyny skuteczny sposób żeby doprowadzić jego stan do ładu jest odbudować go ponownie. Niestety, pt-table-sync nie zawsze sobie radzi. W przypadku InnoDB rozwiązaniem byłoby zabicie wątku SQL replikacji a następnie ponowienie zapytań, tyle że w poprawnej formie.

Nie można wspomnieć także o innym „feature” MyISAM, jakim jest tendencja do uszkadzania się struktury indeksów. Ile to razy odpalaliśmy REPAIR TABLE na uszkodzonej tabeli? Ile to trwa w przypadku tabel rzędu kilkadziesiąt giga? Oczywiście, jak wszyscy wiemy, REPAIR TABLE skutecznie wyłącza tabelę z użytku, czyli w przypadku dużej tabeli część danych przez kilka (-naście/-dziesiąt) godzin może nie być dostępna.

Dla mnie osobiście to właśnie są problemy, które sprawiają, że zastanowię się tysiąc razy zanim wykorzystam MyISAM do czegokolwiek. Szczególnie, że z 5.6 i wyszukiwaniem pełnotekstowym w InnoDB jest już coraz mniej zastosowań, w których InnoDB nie dałoby się wykorzystać. Choćby dziś rano, przeglądając posty w Planet MySQL trafiłem na ten: http://mysqlblog.fivefarmers.com/2012/11/15/innodb-now-works-with-read-only-media/
Znika jeszcze jedna nisza, w której MyISAM nie mógł być zastąpiony przez InnoDB (do tej pory InnoDB wymagało możliwości zapisu na nośniku, gdzie było zainstalowane)