Jestem gotowy na przejście z MyISAM do InnoDB, ale chciałem wiedzieć, czy istnieje pełna lista rzeczy do poszukiwania? Na przykład nie widziałem żadnej wzmianki na liście, że uruchomienie DISABLE KEYSna tabeli InnoDB spowoduje wyświetlenie ostrzeżenia, z wyjątkiem strony podręcznika dla ALTER TABLE. Jest to coś, o czym muszę wiedzieć przed konwersją. Myślałem, że z moimi pytaniami nic mi nie będzie, ale najwyraźniej nie.

Oto kilka gotchas

Zużycie pamięci

MyISAM

• tylko buforuje strony indeksowe.
• współdzielony keycache (rozmiar według key_buffer_size).
• Możesz także skonfigurować dedykowany keycache, jedną lub więcej tabel na tabelę pamięci podręcznej .

InnoDB

• buforuje strony danych i strony indeksu.
• jedna pula buforów i jeden rozmiar przed MySQL 5.5
• 1 lub więcej pul buforów zaczynających się od MySQL 5.5

Oto kilka zapytań, które napisałem i opublikowałem wcześniej, jak wybrać odpowiedni rozmiar pamięci podręcznej kluczy MyISAM i puli buforów InnoDB .

Indeksy FULLTEXT

MyISAM

• Obsługuje indeksy FULLTEXT

InnoDB

• Począwszy od MySQL 5.6, tak, ale wciąż w wersji beta (AKTUALIZACJA: MySQL 5.6 istnieje i ma indeksy FULLTEXT. Jeśli używasz indeksowania FULLTEXT w MySQL 5.6, upewnij się, że korzystasz z opcji FULLTEXT specyficznych dla InnoDB )
• W wersjach wcześniejszych niż MySQL 5.6 oznacza to, że nie można przekonwertować MyISAM na InnoDB.

MySQL 5.5 i nowsze

Aby zlokalizować, które tabele MyISAM mają indeks FULLTEXT, uruchom następujące zapytanie:

select tbl.table_schema,tbl.table_name from
(
    select table_schema,table_name
    from information_schema.tables
    where engine='MyISAM'
    and table_schema NOT IN ('information_schema','mysql')
) tbl
INNER JOIN
(
    select table_schema,table_name
    from information_schema.statistics
    where index_type='FULLTEXT'
) ndx
USING (table_schema,table_name);

Cokolwiek wyjdzie z tego zapytania, nie można przekonwertować na InnoDB, dopóki nie zaktualizujesz do MySQL 5.6.

OPTYMALIZUJ TABELĘ

MyISAM

• Stół MyISAM jest zmniejszony
• ANALYZE TABLE uruchamia statystyki indeksów dla wszystkich indeksów

InnoDB

• TABELA ANALIZOWA jest całkowicie bezużyteczna, ponieważ statystyki indeksów są zawsze przywoływane
• Po wyłączeniu innodb_file_per_table , ibdata1 będzie większy
• Z innodb_file_per_table włączona, plik tabel (.ibd) kurczy

Wydaje mi się, że największą gotcha byłby w transakcjach. Będziesz chciał wiedzieć, czy biblioteki MySQL są domyślnie używane przez aplikacje auto_commit, czy nie.

Na przykład Python nie dokonuje automatycznego zatwierdzania. Oznacza to, że jeśli aplikacja wstawiała wiersz tuż przed zamknięciem swojego połączenia, wstawka zostanie teraz wycofana po przejściu na innodb. Na przykład skrypt Pythona musiałby koniecznie wywołać connection.commit ();

Kolejna różnica może dotyczyć wstawek wielorzędowych lub aktualizacji. Rozważ jedno wstawienie wielorzędowe

insert into tbl values (...row1...),  (...row2...),  (...rowN....);

Zastanów się, co się stanie, jeśli wystąpi jakiś błąd, taki jak unikalna kolizja kluczy w wierszu 3. W MyISAM pierwsze dwa wiersze zostałyby zapisane, w innodb wszystkie zapisane wiersze zostałyby wycofane, nie pozostawiając niczego zapisanego nawet przy takim błędzie.

Z innodb wejdziesz do świata impasu. Nie są one z natury złe, chyba że występują z taką częstotliwością, aby uniemożliwić wykonanie jakiejkolwiek pracy. Jednak aplikacje będą musiały zostać zakodowane w taki sposób, aby przewidywały zakleszczenia i odpowiednio je obsługiwały (co najprawdopodobniej oznacza po prostu ponów próbę).

Rozważ ograniczenia pamięci / pamięci. Innodb wymaga znacznie więcej zasobów niż MyISAM. Jeśli masz wystarczającą ilość pamięci RAM, aby pule buforów były wystarczająco duże, aby pomieścić wszystkie stoły, to jesteś złoty.

Poszukaj tabel, które mają duże klucze podstawowe. Indeksowanie klastrowe Innodb oznacza, że ​​każdy indeks wtórny zawiera inną kopię PK odpowiedniego wiersza. Jeśli masz 2 indeksy wtórne, oznacza to, że każdy wiersz PK jest zapisywany 3 razy (PK + każdy indeks). Jeśli pk rozciąga się na kilka typów kolumn i dużych typów danych (na przykład char (N)), możesz zobaczyć, jak wymagania indeksu mogą szybko eksplodować pod innodb.