it-swarm-eu.dev

Best of MyISAM und InnoDB

Ist es möglich, InnoDB dazu zu bringen, Indizes wie MyISAM anstelle von Clustered Index zu verwenden, da RAM) begrenzt ist und gleichzeitig die Parallelitätsleistung genutzt wird?

17
Rick James

Der gen_clust_index (Clustered Index) unter der Haube von InnoDB enthält Einträge von Primärschlüsseln zusammen mit Rowids. Das Interessante an der Verwendung des gen_clust_index ist die Tatsache, dass alle nicht eindeutigen Indizes, die Sie erstellen, immer eine entsprechende Zeilen-ID für den gen_clust_index einer Tabelle haben. Daher gibt es immer Doppelindex-Lookups, eine für den Sekundärindex und eine für den gen_clust_index.

Alle Versuche, das Layout einer Tabelle oder eines Primärschlüssels zu verbessern, werden aufgrund des gen_clust_index oder zumindest marginaler Ergebnisse zunichte gemacht.

BEISPIEL

Einige Leute versuchen, ein MyISAM in der Reihenfolge PRIMARY KEY zu sortieren. Gemäß MySQL Database Design and Tuning, Seite 236, Absatz 7, unter der Überschrift "Speichern einer Tabelle in Indexreihenfolge" :

Wenn Sie häufig große Bereiche indizierter Daten aus einer Tabelle abrufen oder Ergebnisse konsistent nach demselben Indexschlüssel sortieren, sollten Sie myisamchk mit der Option --sort-records ausführen. Wenn Sie dies tun, weisen Sie MySQL an, die Daten der Tabelle in derselben physischen Reihenfolge wie den Index zu sortieren, und können Sie diese Art von Vorgängen beschleunigen. Alternativ können Sie die Anweisung ALTER TABLE mit einer Option ORDER BY einer bestimmten Spalte kombinieren, um dieselben Ergebnisse zu erzielen.

Zugegeben, dies funktioniert und funktioniert effektiv FÜR MyISAM . Sie können ALTER TABLE ... ORDER BY col1, col2, ..., coln für InnoDB ausführen, wobei die Spalten möglicherweise die des PRIMARY KEY sind oder nicht. Dies führt nicht zu schnelleren Ergebnissen für InnoDB, da ... das ist richtig ... Sie jedes Mal den gen_clust_index konsultieren müssen.

Einige Leute können das Zeilenformat der Tabelle mit ALTER TABLE mydb.mytb ROW_FORMAT=Fixed; und kann die Leseleistung ohne weitere Änderungen um 20% steigern. Dies funktioniert und funktioniert effektiv FÜR MyISAM . Dies führt nicht zu schnelleren Ergebnissen für InnoDB, da ... das ist richtig ... Sie jedes Mal den gen_clust_index konsultieren müssen.

Sie können Folgendes für eine InnoDB-Tabelle mit dem Namen mydb.mytb ausführen:

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;

Dadurch wird die Tabelle im gen_clust_index in Zeilenreihenfolge gebracht. Dies kann bestenfalls zu geringfügigen Ergebnissen für InnoDB führen, da ... das ist richtig ... Sie jedes Mal den gen_clust_index konsultieren müssen.

Lassen Sie uns jetzt ein wenig lächerlich werden. Es gibt eine NoSQL-Schnittstelle zum Abfragen (nur SELECT). MyISAM und InnoDB heißen HandlerSocket (früher HANLDER genannt) . Auf diese Weise erhalten Sie Zugriff auf Daten, mit denen Sie alle SQL-Anweisungen umgehen können: ACID und MVCC = Protokolle. Obwohl es möglich ist, IMHO WEG ZU KOMPLIZIERT, um zu codieren und zu pflegen. AFAIK Es gibt nichts im Druck, was angibt, ob die HandlerSocket-Schnittstelle mit dem gen_clust_index interagiert oder nicht.

Zusammenfassend gibt es viele Möglichkeiten, eine Katze zu häuten. In diesem Fall können Sie die Katze (den gen_clust_index) nicht erreichen. Ich denke, dies ist der Grund, warum MyISAM aufgrund seiner Leseleistung, seiner Flexibilität bei der Tabellenreihenfolge, des Tabellenzeilenformats und der Tools, die dies unterstützen, weiterhin existiert. InnoDB wird weiterhin auf seine ACID-konforme Natur ausgelegt sein bis eine mutige Seele den InnoDB-Quellcode nimmt und ihn in etwas verwandelt, das das Beste aus MyISAM und InnoDB hat.

14
RolandoMySQLDBA

Kurze Antwort: Nein.

InnoDB gruppiert sich über den Primärschlüssel und wählt in Abwesenheit eines Primärschlüssels den ersten eindeutigen Index aus. Wenn kein eindeutiger Index vorhanden ist, wird ein versteckter 6-Byte-Schlüssel für das Clustering erstellt.

Wenn Sie den versteckten 6-Byte-Schlüssel haben, beziehen sich alle Sekundärindizes auf diesen Schlüssel und nicht auf exakte Zeiger auf Zeilenpositionen (wie in MyISAM). Sie erhalten also eine Sekundärschlüssel-Durchquerung und dann eine Primärschlüssel-Durchquerung, um Ihre Datensätze zu finden .


Um ein wenig von Ihrer Frage zu extrapolieren, gehe ich davon aus, dass Sie sich Sorgen über die Speicheranpassung an einen Baum machen, denn um effizient zu suchen, sollten sich alle Stammknoten im Speicher befinden, da Sie immer diesen Pfad gehen müssen, um Ihre Blattseiten zu finden.

Dies ist wahr, aber ein Trost ist, dass kommerzielle Datenbanken versuchen, ihre Bäume so fett wie möglich und nicht tief zu machen. Versuchen Sie, xtrabackup --stats für Ihre Daten auszuführen, um sie anzuzeigen. Zum Beispiel:

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

Es gab 497839 Blattseiten (~ 8 GB), aber nur 416 Seiten darüber (6,5 MB). Ich habe diesen Befehl einige Male für Produktionsdaten ausgeführt, und es überrascht mich immer wieder, wenn ich Millionen Milliarden Datensätze und nur Seiten der Stufen 1-3 + Blattseiten habe.

3
Morgan Tocker

Der Clustered Index ist möglicherweise der Grund für die Parallelitätsleistung von InnoDB auf herkömmlichen Spin-Laufwerken.

Der Zugriff auf eine Zeile über den Clustered-Index ist schnell, da sich die Zeilendaten auf derselben Seite befinden, zu der die Indexsuche führt. Wenn eine Tabelle groß ist, speichert die Clustered-Index-Architektur im Vergleich zu Speicherorganisationen, die Zeilendaten auf einer anderen Seite als dem Indexdatensatz speichern, häufig eine Festplatten-E/A-Operation. (MyISAM verwendet beispielsweise eine Datei für Datenzeilen und eine andere für Indexdatensätze.)

Festplatten-E/A ist teuer. Das zu reduzieren ist also ein großer Vorteil, um die Parallelität zu verbessern.

Wenn Festplatten-E/A billiger und weniger eng werden (z. B. wenn die SSD-Technologie stabiler wird), kann Oracle entscheiden, die Funktionsweise von InnoDB-Indizes zu ändern. Wahrscheinlicher ist, dass dies gleich bleibt, da durch dieselbe Technologie die Beschränkung des Arbeitsspeichers weniger problematisch wird.

3
Derek Downey