Najlepsze z MyISAM i InnoDB

Czy można zmusić InnoDB do używania indeksów takich samych jak MyISAM zamiast indeksu klastrowego z powodu ograniczenia pamięci RAM, jednocześnie uzyskując korzyści z wydajności współbieżności?

Gen_clust_index (skupione index) pod maską InnoDB mieści pozycji kluczy pierwotnych wraz z rowids. Interesujące w zastosowaniu gen_clust_index jest fakt, że wszelkie nieunikalne indeksy, które utworzysz, zawsze będą miały odpowiadający identyfikator wiersza dla gen_clust_index tabeli. Dlatego zawsze istnieją wyszukiwania podwójnych indeksów, jeden dla indeksu dodatkowego i jeden dla indeksu gen_clust_index.

Wszelkie próby ulepszenia układu tabeli lub klucza podstawowego zostają unieważnione z powodu gen_clust_index lub przynajmniej w najlepszym razie wyników marginalnych.

PRZYKŁAD

Niektóre osoby próbują posortować MyISAM w PIERWSZEJ KLUCZY. Zgodnie z projektowaniem i dostrajaniem bazy danych MySQL, § 23, pod podtytułem „Przechowywanie tabeli w porządku indeksu”:

Jeśli często pobierasz duże zakresy indeksowanych danych z tabeli lub konsekwentnie sortujesz wyniki według tego samego klucza indeksu, możesz rozważyć uruchomienie myisamchk z opcją --sort-records. W ten sposób powiedz MySQL, aby posortował dane tabeli w tej samej fizycznej kolejności co indeks, i może to przyspieszyć tego rodzaju operacje. Alternatywnie można połączyć instrukcję ALTER TABLE z poleceniem ORDER BY określonej kolumny, aby osiągnąć te same wyniki.

To prawda, działa to i działa efektywnie dla MyISAM . Możesz wykonać ALTER TABLE ... ORDER BY col1, col2, ..., coln przeciwko InnoDB, gdzie kolumny mogą, ale nie muszą, być kluczem podstawowym. Nie przyniesie to szybszych rezultatów dla InnoDB, ponieważ ... właśnie tak ... za każdym razem musisz skonsultować się z gen_clust_index.

Niektóre osoby mogą ustawić NAPRAWIONY format wiersza tabeli za pomocą ALTER TABLE mydb.mytb ROW_FORMAT=Fixed;i mogą uzyskać 20% wzrost wydajności odczytu bez żadnych innych zmian. Działa to i działa skutecznie w przypadku MyISAM . Nie przyniesie to szybszych rezultatów dla InnoDB, ponieważ ... właśnie tak ... za każdym razem musisz skonsultować się z gen_clust_index.

Możesz wykonać następujące czynności w tabeli InnoDB o nazwie mydb.mytb:

CREATE TABLE mydb.mytc LIKE mydb.mytb;
INSERT INTO mydb.mytc SELECT * FROM mydb.mytb ORDER BY col1,col2,...coln;
ALTER TABLE mydb.mytb RENAME mydb.mytd;
ALTER TABLE mydb.mytc RENAME mydb.mytb;
DROP TABLE mydb.mytd;

Spowoduje to umieszczenie tabeli w rzędzie w indeksie gen_clust_index. Może to w najlepszym wypadku generować marginalne wyniki dla InnoDB, ponieważ ... właśnie tak ... za każdym razem musisz skonsultować się z gen_clust_index.

A teraz bądźmy trochę niedorzeczni. Istnieje interfejs NoSQL do zapytania (tylko SELECT) MyISAM i InnoDB o nazwie HandlerSocket (wcześniej HANLDER) . Daje to dostęp do danych, które pozwalają ominąć wszystkie protokoły SQL, ACID i MVCC . Chociaż jest to możliwe, IMHO SPOSÓB ZBYT ZGODNE Z KODEM I UTRZYMANIA AFAIK w druku nie ma nic, co wskazywałoby, czy interfejs HandlerSocket współdziała z indeksem gen_clust_index, czy nie.

Podsumowując, istnieje wiele sposobów na skórowanie kota. W takim przypadku nie możesz zdobyć kota (gen_clust_index). Wydaje mi się, że właśnie dlatego MyISAM nadal istnieje pod względem wydajności odczytu, elastyczności w porządkowaniu tabel, formatu wierszy tabeli i narzędzi do tego wspierających. InnoDB pozostanie zaprojektowane wokół swojej natury zgodnej z ACID, dopóki pewna dzielna dusza nie pobierze kodu źródłowego InnoDB i przekształci go w coś, co ma najlepsze cechy zarówno MyISAM, jak i InnoDB .

Indeks klastra jest chyba powodem wydajności współbieżności InnoDB w sprawie tradycyjnych dysków wirowania.

Dostęp do wiersza za pośrednictwem indeksu klastrowego jest szybki, ponieważ dane wiersza znajdują się na tej samej stronie, na której prowadzi wyszukiwanie indeksu. Jeśli tabela jest duża, architektura indeksów klastrowych często zapisuje operację We / Wy dysku w porównaniu z organizacjami pamięci masowej, które przechowują dane wierszy przy użyciu innej strony niż rekord indeksu. (Na przykład MyISAM używa jednego pliku dla wierszy danych, a drugiego dla rekordów indeksu.)

Dysk I / O jest drogi. Zmniejszenie tego jest ogromną korzyścią dla poprawy współbieżności.

Jeśli dyskowe operacje we / wy zaczynają być tańsze i stają się wąskim gardłem (np. Gdy technologia SSD staje się bardziej stabilna), Oracle może zdecydować o zmianie sposobu działania indeksów InnoDB. Bardziej prawdopodobne jest, że pozostanie taki sam, ponieważ ta sama technologia sprawi, że „ograniczenie pamięci RAM” będzie mniejszym problemem.

Krótka odpowiedź: Nie.

Klastry InnoDB za pośrednictwem klucza podstawowego, a przy braku klucza podstawowego, wybiera pierwszy unikalny indeks. W przypadku braku unikalnego indeksu tworzy ukryty 6-bajtowy klucz do grupowania.

Gdy masz ukryty klucz 6-bajtowy, wszelkie indeksy wtórne odnoszą się do tego klucza, a nie dokładne wskaźniki do lokalizacji wierszy (jak w MyISAM), więc kończy się przejściem do klucza dodatkowego, a następnie przejściem do klucza podstawowego, aby znaleźć swoje rekordy .

Aby ekstrapolować trochę z twojego pytania, zakładam, że martwisz się dopasowaniem pamięci do drzewa, ponieważ aby skutecznie wyszukiwać, wszystkie węzły główne powinny być w pamięci, ponieważ zawsze musisz iść tą ścieżką, aby znaleźć swoje strony z liśćmi?

To prawda, ale jedną pociechą jest to, że komercyjne bazy danych starają się, aby ich drzewa były tak grube, jak to możliwe, a nie głębokie. Spróbuj uruchomić xtrabackup - staty na danych, aby zobaczyć. Na przykład:

<INDEX STATISTICS>
  table: test/table1, index: PRIMARY, space id: 12, root page 3
  estimated statistics in dictionary:
    key vals: 25265338, leaf pages 497839, size pages 498304
  real statistics:
     level 2 pages: pages=1, data=5395 bytes, data/pages=32%
     level 1 pages: pages=415, data=6471907 bytes, data/pages=95%
        leaf pages: recs=25958413, pages=497839, data=7492026403 bytes, data/pages=91%

Było 497839 stron liści (~ 8 GB), ale tylko 416 stron powyżej (6,5 MB). Uruchomiłem to polecenie kilka razy na danych produkcyjnych i zawsze mnie to zaskakuje, gdy mam miliony miliardów rekordów i tylko poziomy 1-3 stron + strony z listkami.