Jakie tabele należy migrować do InnoDB, a które powinny pozostać MyISAM?

10

Jak w tytule: Czy istnieje krótka lista kandydatów do migracji tabel do InnoDB? I co powinno pozostać MyISAM.

Niektóre dodatkowe informacje

  • Witryna ma dość duże obciążenie odczytu, ale wstawia około 10 węzłów na godzinę, z tagami i tym podobne.
  • W dużym stopniu korzystamy z CCK (ogromna ilość znormalizowanych tabel w postaci content_field%).
  • Korzystamy również z widoków dla wszystkich naszych bloków i stron; ale wiele z nich kwalifikuje się do zastąpienia niestandardowymi modułami (w celu zmniejszenia liczby zapytań do bazy danych i ciężkości tych zapytań).
  • Użytkownicy są anonimowi; z wyjątkiem kilku zalogowanych edytorów i webmasterów.
performance database berkes
źródło
To zabawne, że cały internet nie ma pojęcia, jak odpowiedzieć na to pytanie. Które tabele Drupala zajmują najwięcej zapisów i zostają zablokowane ... kto wie.
JM Becker,

Odpowiedzi:

8

Powinieneś przekonwertować wszystkie dane na InnoDB, aby zapobiec problemom z blokowaniem tabeli. Oto jednak kilka rzeczy do przemyślenia:

Indeksowanie FULLTEXT

Obecnie tylko MyISAM obsługuje indeksowanie FULLTEXT. Indeksowanie FULLTEXT dla InnoDB jest obecnie w fazie prac dla MySQL 5.6, ale nie jest gotowe do produkcji . Jeśli masz jakieś tabele Drupal, które mają indeksy FULLTEXT, nie można ich teraz przekonwertować na InnoDB.

AKTUALIZACJA przy indeksowaniu PEŁNYM TEKSTEM

MySQL 5.6 jest teraz GA (obecnie do użytku produkcyjnego). Wypróbuj indeksowanie FULLTEXT w InnoDB.

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

SELECT table_schema,table_name
FROM information_schema.statistics
WHERE index_type='FULLTEXT';

Jeśli nie wrócą żadne wiersze, przekonwertuj wszystkie tabele InnoDB na zawartość twojego serca. Napisałem wcześniejszy post na temat konwertowania wszystkich tabel MyISAM na InnoDB przy użyciu tylko mysql .

Replikacja MySQL

Jeśli masz duże środowisko do odczytu, odczyty mogą przebiegać szybciej w MyISAM, jeśli wykonasz następujące czynności:

  • Skonfiguruj replikację Master / Slave
  • Stwórz jedno lub więcej Read Slaves pod Master
  • Dodaj --skip-innodbplik /etc/my.cnf na wszystkich urządzeniach Slave (konwertuje tabele na MyISAM podczas ładowania danych do urządzenia Slave)
  • Zmień format wiersza wszystkich tabel MyISAM w każdym Slave na NAPRAWIONO za pomocą tego polecenia: ALTER TABLE tblname ROW_FORMAT=FIXED;
  • Coś o tym napisałem w DBA StackExchange
  • Książka Projektowanie i dostrajanie bazy danych MySQL zaleca korzystanie ROW_FORMAT=FIXEDze stron 72, 73. Spowoduje to wewnętrzną konwersję wszystkich pól VARCHAR na CHAR. Sprawi to, że tabela MyISAM będzie większa, ale wykonanie na niej SELECT będzie znacznie szybsze. Mogę osobiście to poświadczyć. Kiedyś miałem stół o pojemności 1,9 GB. Zmieniłem format za pomocą ALTER TABLE tblname ROW_FORMAT=FIXED. Tabela skończyła się 3,7 GB. Szybkość WYBORÓW przeciwko niemu była o 20-25% większa bez poprawy lub zmiany czegokolwiek innego.

Jedyny problem związany z tym polega na uświadomieniu Twojej aplikacji osobnych czytników podrzędnych.

EPILOG

Jeśli patrzysz na inne korzyści, jakie ma każdy silnik pamięci, sprawdź DBA StackExchange:

RolandoMySQLDBA
źródło
4

Ponieważ twoja strona jest przeznaczona do odczytu, po prostu przekonwertowałbym wszystkie tabele na InnoDB. Będziesz wtedy mógł zoptymalizować wydajność odczytu, odpowiednio dobierając pulę buforów InnoDB i pamięć podręczną zapytań. W ten sposób osiągamy kilka tysięcy zapytań na sekundę na dedykowanych serwerach baz danych w naszej infrastrukturze hostingowej Drupal.

geewiz
źródło