it-swarm-eu.dev

To nejlepší z MyISAM a InnoDB

Je možné, aby InnoDB používal indexy stejné jako MyISAM místo klastrovaného indexu kvůli omezení RAM při současném získání výhody jeho souběžného výkonu?

17
Rick James

gen_clust_index (seskupený index) pod kapotou InnoDB obsahuje položky primárních klíčů spolu s rowids. Co je zajímavé na použití gen_clust_index je skutečnost, že všechny nejedinečné indexy, které vytvoříte, budou mít vždy odpovídající rowid pro gen_clust_index tabulky. Proto vždy existují dvojí vyhledávání indexů, jedno pro sekundární index a druhé pro gen_clust_index.

Jakékoli pokusy o zlepšení rozvržení tabulky nebo primárního klíče jsou anulovány kvůli gen_clust_index nebo přinejmenším okrajovým výsledkům.

PŘÍKLAD

Někteří lidé se pokusí třídit MyISAM v pořadí PRIMARY KEY. Podle MySQL Database Design and Tuning, Page 236 Odstavec 7, pod podtitulem „Ukládání tabulky do indexu“:

Pokud často načítáte velké rozsahy indexovaných dat z tabulky nebo důsledně seřadíte výsledky na stejném indexovém klíči, můžete zvážit spuštění myisamchk s volbou --sort-records. Pokud tak učiníte, řekněte MySQL, aby se data tabulky třídila ve stejném fyzickém pořadí jako index, a mohou pomoci urychlit tyto druhy operací. Případně můžete kombinovat příkaz ALTER TABLE s možností OBJEDNAT podle konkrétního sloupce, abyste dosáhli stejných výsledků.

Je pravda, že to funguje a funguje efektivně FOR MyISAM . Můžete provést ALTER TABLE ... ORDER BY col1, col2, ..., coln proti InnoDB, kde sloupce mohou nebo nemusí být sloupci PRIMARY KEY. To pro InnoDB nepřinese rychlejší výsledky, protože ... to je pravda ... musíte se vždy poradit s gen_clust_index.

Někteří lidé mohou upravit formát řádků tabulky FIXED pomocí ALTER TABLE mydb.mytb ROW_FORMAT=Fixed; a může dosáhnout zvýšení výkonu čtení o 20% bez jakýchkoli dalších změn. Funguje to a funguje efektivně PRO MyISAM . To pro InnoDB nepřinese rychlejší výsledky, protože ... to je pravda ... musíte se vždy poradit s gen_clust_index.

V tabulce InnoDB s názvem mydb.mytb můžete provést následující:

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;

Tím se tabulka v řádkovém pořadí v gen_clust_index. To může přinést nejlepší výsledky pro InnoDB, protože ... to je pravda ... musíte se vždy poradit s gen_clust_index.

Teď se trochu směšné. Existuje rozhraní NoSQL pro dotaz (pouze SELECT) MyISAM a InnoDB nazvané rozhraní HandlerSocket (dříve nazývané HANLDER) . Tím získáte přístup k datům, která vám umožní obejít všechny SQL, KYSELINA a MVCC = protokoly. I když je to možné, IMHO WAY TOO KOMPLIKOVANÝ KÓD A ÚDRŽBU. AFAIK není v tisku nic uvádějící, zda rozhraní HandlerSocket interaguje s gen_clust_index nebo ne.

Stručně řečeno, existuje mnoho způsobů, jak kůži kočku. V tomto případě nemůžete chytit kočku (gen_clust_index). Myslím, že to je důvod, proč MyISAM nadále existuje pro svůj čtecí výkon, jeho ohebnost při řazení tabulky, formát řádků tabulky a nástroje, které jej podporují. InnoDB zůstane navrženo podle své ACID kompatibilní povahy dokud nějaká statečná duše nepřijme zdrojový kód InnoDB a nepřevede jej do něčeho, co má nejlepší z MyISAM i InnoDB.

14
RolandoMySQLDBA

Krátká odpověď: Ne.

Klastry InnoDB prostřednictvím primárního klíče a pokud neexistuje primární klíč, vybere první jedinečný index. Při neexistenci jedinečného indexu vytvoří skrytý 6 bajtový klíč pro klastrování.

Pokud máte skrytý 6 bajtový klíč, všechny sekundární indexy odkazují na tento klíč, nikoli na přesné ukazatele na umístění řádků (jako v MyISAM), takže skončíte přechodem sekundárního klíče a poté procházením primárním klíčem k nalezení záznamů. .


Abych trochu extrapoloval z vaší otázky, předpokládám, že si děláš starosti s pamětí zapadající do stromu, protože pro efektivní vyhledávání by všechny kořenové uzly měly být v paměti, protože vždy musíš jít touto cestou, abys našel své listové stránky?

To je pravda, ale jednou útěchou je, že komerční databáze se snaží, aby jejich stromy byly co nejtučnější, než aby byly hluboké. Zkuste zobrazit xtrabackup --stats na svých datech. Například:

<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%

Tam bylo 497839 listových stránek (~ 8 GB), ale pouze 416 stránek výše (6,5 MB). Tento příkaz jsem několikrát spustil na produkčních datech a vždy mě překvapí, když mám miliony miliard záznamů a pouze úrovně 1-3 stránky + listové stránky.

3
Morgan Tocker

seskupený index je možná důvodem souběžného výkonu InnoDB na tradičních discích.

Přístup k řádku prostřednictvím seskupeného indexu je rychlý, protože data řádků jsou na stejné stránce, kde vede hledání indexu. Pokud je tabulka velká, architektura seskupeného indexu často ukládá operaci disk I/O ve srovnání s organizacemi úložišť, které ukládají data řádků pomocí jiné stránky než záznam indexu. (Například MyISAM používá jeden soubor pro datové řádky a druhý pro indexové záznamy.)

Diskové V/V je drahé. Snížení je tedy obrovským přínosem pro zlepšení souběžnosti.

Pokud se diskové I/O začnou zlevňovat a méně omezovat (např. Jak se technologie SSD stává stabilnější), může se Oracle rozhodnout změnit způsob fungování indexů InnoDB. S větší pravděpodobností to zůstane stejné, protože stejná technologie způsobí, že omezení RAM bude méně problémové.

3
Derek Downey