Jak wybrać silnik bazy danych MySQL

W szczególności, w jaki sposób wybierasz między MyISAM i InnoDB, gdy żadna z nich nie brakuje wymaganej funkcji (np. Nie potrzebujesz kluczy obcych).

Czy zawsze sprowadza się to do wypróbowania obu metod i pomiaru? Czy też istnieją dobre ogólne zasady dotyczące liczby i częstotliwości odczytów w porównaniu do zapisów i innych podobnych środków? Czy rozmiar stołu ma wpływ na typowy wybór?

Odpowiedź brzmi: zawsze powinieneś mierzyć, najlepiej z własnymi danymi i obciążeniem, jeśli to w ogóle możliwe.

Ponieważ wzorce dostępu do danych mogą się znacznie różnić w zależności od aplikacji, trudno powiedzieć i najprawdopodobniej niemożliwe jest określenie „najlepszego” silnika pamięci masowej dla wszystkich obciążeń.

Są jednak bardzo zachęcające zmiany w przestrzeni MySQL, które wzięły udział w MySQLConf / Percona Performance Conf w zeszłym tygodniu.

Niektóre z alternatywnych silników pamięci masowej:

1. XtraDB (widelec InnoDB)
2. Wtyczka InnoDB
3. PBXT
4. TokuDB

Dodatkowo Percona, Google itp. Wnieśli poprawki, które znacznie pomagają w wydajności InnoDB. Osobiście prowadzę kompilację OurDelta. Działa dla mnie ładnie i zachęcam do zapoznania się z kompilacjami OurDelta i Percona.

Jeśli jest to prosty system sklepu / raportów, używam MyISAM ze względu na jego surową wydajność.

Używałbym InnoDB, gdybym był zaniepokojony wieloma jednoczesnymi dostępami z dużą ilością zapisów, aby skorzystać z blokowania na poziomie wiersza.

Istnieje wiele testów porównawczych dla różnych silników baz danych MySQL. Jest przyzwoity porównujący MyISAM, InnoDB i Falcon na blogu Percona MySQL Performance , patrz tutaj .

Kolejną rzeczą do rozważenia między dwoma wyżej wymienionymi silnikami (MyISAM i InnoDB) są ich podejścia do blokowania. MyISAM wykonuje blokowanie tabeli, podczas gdy InnoDB blokuje wiersze. Jest wiele rzeczy do rozważenia, nie tylko zwykłe wyniki.

Istnieją funkcje, które okażą się bardzo przydatne ze względów operacyjnych, nawet jeśli aplikacja ich absolutnie nie wymaga:

• InnoDB ma MVCC, co oznacza, że ​​możesz wykonywać nieblokujące spójne kopie zapasowe
• InnoDB ma automatyczne odzyskiwanie, co oznacza brak długich operacji NAPRAWY TABELI po nieczystym wyłączeniu
• Dzięki InnoDB czytelnicy nigdy nie blokują programów piszących i vice versa, co oznacza (ogólnie mówiąc) większą współbieżność (nie musi to jednak oznaczać lepszej wydajności w ogólnym przypadku)
• InnoDB grupuje swoje wiersze na kluczu podstawowym, co MOŻE oznaczać mniej operacji IO dla operacji odczytu, JEŻELI klucz podstawowy został wybrany wystarczająco dobrze.

Niezależnie od ograniczeń klucza obcego, prawdopodobnie i tak chcesz użyć InnoDB.

oczywiście jest to Błąd serwera, a nie Przepełnienie stosu, więc poprawna odpowiedź to:

• Zawsze musisz korzystać z silnika wybranego przez twórców aplikacji
• Jeśli nie wybrali konkretnego silnika, nie traktują poważnie MySQL i prawdopodobnie nie wiedzą, jak go właściwie używać.
• Nie możesz przejść na inny silnik niż ten, na którym testowana była twoja aplikacja, może to powodować błędy.

Mój dostawca hostingu poradził nam, aby całkowicie pozbyć się MyISAM i przejść na InnoDB, chyba że nie jest to możliwe.

W naszym przypadku mieliśmy poważne uszkodzenie danych, które zaczęło pojawiać się od kilku razy do kilku razy dziennie, zawsze wymagając naprawy tabeli naprawczej i powiązanych poleceń, co zajmowało wieki na dużych tabelach.

Po konwersji (lub: konwersji) do InnoDB problemy natychmiast zniknęły. Minusy / zastrzeżenia mieliśmy:

• Nie można przekonwertować tabel z indeksem FULLTEXT (ten problem sam z czasem zniknął; został zastąpiony rozwiązaniem opartym na Solr / Lucene, które i tak ma znacznie lepszą jakość)
• Duże tabele z milionami wierszy, które często wymagają COUNT (*), były bardzo wolne, nie mogliśmy też ich zamienić.

Ale uwaga: wszystko to jest specyficzne dla naszego środowiska itp., Więc może nie mieć zastosowania.