Czy powszechną praktyką jest mieszanie tabel InnoDB i MyISAM na tym samym serwerze?


21

Mam jedną bazę danych o wielkości około 4,5 GB działającą na serwerze z 8 GB pamięci RAM. Zdecydowana większość tabel to MyIsam (około 4,3 GB), ale wkrótce zamierzam przekonwertować niektóre z nich na InnoDB. (To będzie powolny proces, początkowo skupiający się na tabelach najbardziej intensywnych).

Czy jest coś nie tak z uruchomieniem dedykowanego serwera, na którym istnieją oba typy silników pamięci masowej?


Is there anything wrong with running a dedicated server where both types of storage engines exist? Może przeformułowanie na Multiple types?
John

Jedynym powodem, dla którego powiedziałem „oba”, jest to, że pytanie dotyczy dwóch głównych silników skonfigurowanych do „precyzyjnego dostrojenia”. Próbuję zignorować inne typy silników, takie jak MEMORY lub MERGE, które są na tyle rzadkie, że afaik nie są przedmiotem dostrajania wydajności.
Derek Downey

Odpowiedzi:


18

Nie ma nic złego w używaniu wielu silników pamięci masowej na tej samej maszynie fizycznej, o ile rozumiesz zalety i wady każdego z nich. Istnieją względy wydajności, ograniczenia funkcji i przypadki użycia dla wszystkich typów pamięci wtyczek.

Na przykład, jeśli masz mały stolik, który pisze w 90%, możesz wybrać MyISAM. Jeśli dane można łatwo zregenerować i jest to mała tabela, powiedzmy do kolejkowania, możesz wybrać Pamięć. Jeśli masz tabelę, która odczytuje w 90%, a dane muszą tam być, gdy ich szukasz, prawdopodobnie wybierzesz silnik pamięci masowej obsługujący transakcje i konfigurowalną atomowość, taki jak InnoDB. Jeśli chcesz mieć dostęp przez system plików bez szkodliwych danych, możesz wybrać CSV.

Niemniej jednak można bezpiecznie używać wielu silników pamięci masowej w tym samym schemacie, a także hosta fizycznego.

Zauważmy jednak, że twoje bufory odgrywają rolę w tym całym bałaganie. Jeśli korzystasz zarówno z MyISAM, jak i InnoDB, musisz uważać, aby Twój key_buffer i innodb_buffer_pool nie rywalizowały. To z twojej strony wymaga starannego planowania, ale to właśnie robimy.


4
+1 Innym typowym przykładem użycia jest MyISAM dla tabel wymagających wyszukiwania pełnotekstowego i InnoDB dla wszystkich innych tabel.
Asaph

@Aseph: nawet w momencie komentarza InnoDB obsługiwał indeksy pełnotekstowe .
BlueRaja - Danny Pflughoeft

2
^^^^ „Funkcje MySQL 5.6” pojawiły się dopiero w 2013-02-05
losowo

1
@randymelder Ładna odpowiedź. Czy byłbyś w stanie wyjaśnić, co miałeś na myśli mówiąc „Musisz uważać, aby Twój key_buffer i innodb_buffer_pool nie walczyły”?
Neel

1
Chcę udowodnić, że się mylę, ale logika wygląda tutaj odwrotnie niż w przypadku stackoverflow.com/a/6796566/5645769 tutaj.
Tᴀʀᴇǫ Mᴀʜᴍᴏᴏᴅ

7

Nie mogę powiedzieć, czy jest to powszechna praktyka. Mogę powiedzieć o własnym doświadczeniu.

Zawsze używam najlepszego narzędzia do pracy, więc cały czas miksuję silniki. Większość moich projektów używa MyISAM jako domyślnego silnika.

Kiedy potrzebuję specjalnych funkcji dostępnych tylko w InnoDB, wybieram to.

Kiedy tabela jest w większości tylko do odczytu, wybieram silnik archiwizujący, zanim będę mógł mrugnąć.

Wiedząc, że serwer maszynowy ma wystarczającą ilość pamięci, wszystkie moje dane tymczasowe są przechowywane w tabelach sterty.

Widziałem w przeszłości pewne spowolnienia mieszające MyISAM i InnoDB, ale nie jest to specyficzny problem MySQL. Jest to problem projektowy, który nie pojawia się, gdy używasz tylko jednego silnika. Właściwie użycie niewłaściwego silnika powoduje, że większe spowolnienie nie ma znaczenia, czy jest to tylko MyISAM, tylko InnoDB lub połączenie obu. Trudno zdefiniować formułę, aby wiedzieć, kiedy nastąpi spowolnienie. Tylko rzeczywiste testy mogą ci to powiedzieć.

Oczywiście nie można było zachować integralności i spójności, łącząc InnoDB i MyISAM w jednym zapytaniu.


aparat archiwum nie obsługuje indeksowania, więc dlaczego przechowujesz go w archiwum.
user4951

0

Staram się unikać mieszania tabel MyISAM i InnoDB w tej samej bazie danych, ale dzieje się to raczej ze względów higienicznych niż praktycznych. Uważam jednak, że przydatne jest posiadanie bazy danych z tabelami MyISAM do wyszukiwania pełnotekstowego, dzięki czemu mogę uruchomić ją na stronach. Przechowywanie go w osobnej bazie danych z kluczem obcym dla każdego wpisu ułatwia innym programistom pracującym na bazie danych, aby zobaczyć, co się dzieje.


Jak możesz mieć klucze obce podczas korzystania z MyISAM?
a_horse_w_no_name

Zła terminologia, ale działa jak klucz obcy. Przechowuję numer identyfikacyjny elementu z tabeli InnoDB i używam go do wyszukiwania strony w wyniku wyszukiwania.
Kenzo,
Korzystając z naszej strony potwierdzasz, że przeczytałeś(-aś) i rozumiesz nasze zasady używania plików cookie i zasady ochrony prywatności.
Licensed under cc by-sa 3.0 with attribution required.