Hauptfunktionen von InnoDB - Cache einfügen, zweimal schreiben, adaptive Hash-Indexdetails

Zu den wichtigsten Funktionen der InnoDB-Speicher-Engine gehören Einfügepuffer , Double Write und adaptiver Hash- Index. Diese Funktionen sorgen für eine bessere Leistung und höhere Zuverlässigkeit der InnoDB-Speicher-Engine.

Puffer einfügen

Die Einfügepufferung ist das aufregendste der Hauptmerkmale der InnoDB-Speicher-Engine. Der Name könnte jedoch zu der Annahme verleiten, dass der Einfügepuffer Teil des Pufferpools ist. Tatsächlich ist dies nicht der Fall. Obwohl es gut ist, Insert Buffer-Informationen im InnoDB-Pufferpool zu haben, ist Insert Buffer ebenso wie die Datenseite eine Komponente der physischen Seite.

Der Primärschlüssel ist eine eindeutige Kennung für eine Zeile. Zeilendatensätze werden in der Reihenfolge aufsteigender Primärschlüssel in die Anwendung eingefügt. Daher erfolgen Einfügungen in einen gruppierten Index im Allgemeinen sequenziell und erfordern keine wahlfreien Lesevorgänge von der Festplatte.

Beispielsweise definieren wir eine Tabelle gemäß folgendem SQL: create table t (id int auto_increment, name varchar (30), primary key (id));

Die ID-Spalte erhöht sich selbst. Dies bedeutet, dass die ID-Spalte beim Ausführen eines Einfügevorgangs automatisch erhöht wird und die Zeilendatensätze auf der Seite in der Reihenfolge gespeichert werden, in der die ID ausgeführt wird. Normalerweise ist es nicht erforderlich, zum Speichern von Datensätzen zufällig eine andere Seite zu lesen. Daher kann der Einfügevorgang in solchen Fällen im Allgemeinen schnell abgeschlossen werden. Es ist jedoch nicht möglich, für jede Tabelle nur einen Clustered-Index zu haben. In vielen Fällen gibt es für eine Tabelle mehrere nicht-Clustered-Sekundärindizes . Beispielsweise müssen wir auch nach dem Namensfeld suchen, und das Namensfeld ist nicht eindeutig.

Die Tabelle wird durch die folgende SQL-Anweisung definiert: create table t (id int auto_increment, name varchar(30), primary key(id), key(name));

Dadurch wird ein nicht gruppierter und nicht eindeutiger Index erstellt . Beim Ausführen eines Einfügevorgangs werden die Datenseiten zwar noch immer in der Ausführungsreihenfolge des Primärschlüssels id gespeichert , bei nicht gruppierten Indizes erfolgt das Einfügen der Blattknoten jedoch nicht mehr sequenziell. Zu diesem Zeitpunkt ist ein diskreter Zugriff auf nicht gruppierte Indexseiten erforderlich, und die Einfügeleistung wird hier geringer. Dies ist jedoch kein Fehler im Index des Namensfelds, da die Eigenschaften des B+-Baums die Diskretheit der nicht gruppierten Indexeinfügung bestimmen.

Die InnoDB-Speicher-Engine hat den Einfügepuffer innovativ gestaltet . Bei Einfüge- oder Aktualisierungsvorgängen für nicht gruppierte Indizes wird nicht jedes Mal direkt in die Indexseite eingefügt, sondern zunächst ermittelt, ob sich die eingefügte nicht gruppierte Indexseite im Pufferpool befindet . Wenn es vorhanden ist, wird es direkt eingefügt; wenn nicht, wird es zuerst in einen Einfügepuffer gestellt, als ob die Datenbank getäuscht würde, dass dieser nicht gruppierte Index in den Blattknoten eingefügt wurde, und dann wird der Zusammenführungsvorgang des Einfügepuffers und der untergeordneten Knoten der nicht gruppierten Indexseite mit einer bestimmten Häufigkeit ausgeführt . Zu diesem Zeitpunkt können mehrere Einfügungen normalerweise zu einem Vorgang zusammengeführt werden (da sie sich auf einer Indexseite befinden), was die Leistung von Einfüge- und Änderungsvorgängen für nicht gruppierte Indizes erheblich verbessert.

Für die Verwendung der Einfügepufferung müssen die folgenden beiden Bedingungen erfüllt sein:

1. Der Index ist ein Sekundärindex.

2. Der Index ist nicht eindeutig.

Wenn die beiden oben genannten Bedingungen erfüllt sind, verwendet die InnoDB-Speicher-Engine die Einfügepufferung, was die Leistung verbessern kann. Stellen Sie sich jedoch eine Situation vor, in der die Anwendung eine große Anzahl von Einfüge- und Aktualisierungsvorgängen durchführt, die alle nicht eindeutige, nicht gruppierte Indizes betreffen. Wenn die Datenbank während dieses Vorgangs abstürzt, wird eine große Anzahl von Einfügepuffern nicht in den eigentlichen, nicht gruppierten Index integriert. Wenn dies der Fall ist, kann die Wiederherstellung lange dauern und in Extremfällen sogar mehrere Stunden dauern, um einen Zusammenführungswiederherstellungsvorgang durchzuführen.

Hilfsindizes können nicht eindeutig sein, da wir beim Einfügen in den Einfügepuffer keine Suche auf der Indexseite durchführen. Wenn wir danach suchen, wird es definitiv diskrete Lesevorgänge geben und das Einfügen des Puffers verliert seine Bedeutung.

Zeigen Sie die Einfügepufferinformationen an:

Engine-InnoDB-Status anzeigen\G

Die Segmentgröße zeigt, dass die aktuelle Einfügepuffergröße 2 x 16 KB beträgt, die Länge der freien Liste stellt die Länge der freien Liste dar und die Größe stellt die Anzahl der zusammengeführten Datensatzseiten dar.

Die folgende Zeile ist wahrscheinlich das, was uns wirklich interessiert, da sie eine verbesserte Leistung zeigt. „inserts“ stellt die Anzahl der eingefügten Datensätze dar, „merged recs“ stellt die Anzahl der zusammengeführten Seiten dar und „merges“ stellt die Anzahl der Zusammenführungen dar.

Das Verhältnis von zusammengeführten Aufzeichnungen zu Zusammenführungen beträgt etwa 3:1. Dies bedeutet, dass die Einfügepufferung die E/A-Anfragen für nicht gruppierte Indexseiten um etwa das Dreifache reduziert.

Frage:

Derzeit gibt es ein Problem mit dem Einfügepuffer. In schreibintensiven Situationen nimmt der Einfügepuffer zu viel Pufferpoolspeicher in Anspruch. Standardmäßig kann er maximal die Hälfte des Pufferpoolspeichers beanspruchen. Percona hat einige Patches veröffentlicht, um das Problem zu beheben, dass der Einfügepuffer zu viel Pufferpoolspeicher beansprucht. Weitere Informationen finden Sie unter http://www.percona.com/percona-lab.html. Einfach ausgedrückt kann durch Ändern von IBUF_POOL_SIZE_PER_MAX_SIZE die Größe des Einfügepuffers gesteuert werden. Wenn Sie beispielsweise IBUF_POOL_SIZE_PER_MAX_SIZE auf 3 ändern, kann höchstens 1/3 des Pufferpoolspeichers verwendet werden.

Schreibe zweimal

Wenn Einfügepufferung der InnoDB-Speicher-Engine Leistung verleiht, dann sorgen Doppelschreibvorgänge für Datenzuverlässigkeit bei der InnoDB-Speicher-Engine. Wenn die Datenbank abstürzt, kann es vorkommen, dass die Datenbank eine Seite schreibt, aber nur ein Teil der Seite geschrieben wird (beispielsweise werden bei einer 16-KB-Seite nur die ersten 4 KB der Seite geschrieben). Wir nennen das einen teilweisen Seitenschreibvorgang. Bevor die InnoDB-Speicher-Engine die Double-Write-Technologie verwendete, kam es zu Fällen, in denen Daten aufgrund teilweiser Schreibfehler verloren gingen.

Manche Leute glauben vielleicht, dass ein Schreibfehler über das Redo-Protokoll behoben werden kann. Dies ist eine Möglichkeit. Es muss jedoch klar sein, dass das Redo-Log die physischen Vorgänge auf der Seite aufzeichnet , wie z. B. Offset 800, das Schreiben des „aaaa“-Datensatzes. Wenn die Seite selbst beschädigt ist, ist eine Neugestaltung sinnlos. Das heißt, bevor wir das Redo-Log anwenden, benötigen wir eine Kopie der Seite . Wenn ein Schreibfehler auftritt, wird die Seite zuerst durch die Kopie der Seite wiederhergestellt und dann erneut ausgeführt . Dies ist ein doppeltes Schreiben.

Die Architektur der InnoDB-Speicher-Engine Doublewrite ist in Abbildung 2-4 dargestellt.

Doublewrite besteht aus zwei Teilen: Der eine ist der Doublewrite-Puffer im Speicher , der 2 MB groß ist; der andere sind 128 aufeinanderfolgende Seiten im gemeinsam genutzten Tablespace auf der physischen Festplatte, also zwei Extents, die ebenfalls 2 MB groß sind (eine Kopie der Seite) . Wenn die Dirty Page des Pufferpools aktualisiert wird, wird sie nicht direkt auf die Festplatte geschrieben. Stattdessen wird die Dirty Page über die Funktion memcpy in den Doublewrite-Puffer im Speicher kopiert . Anschließend wird sie über den Doublewrite-Puffer zweimal (jeweils 1 MB) auf die physische Festplatte des gemeinsam genutzten Tablespace geschrieben . Anschließend wird die Funktion fsync sofort aufgerufen, um die Festplatte zu synchronisieren und Probleme durch gepuffertes Schreiben zu vermeiden. Da bei diesem Verfahren die Seiten mit doppeltem Schreibzugriff kontinuierlich sind, wird der Vorgang sequenziell geschrieben und der Overhead ist nicht sehr groß. Nachdem das Schreiben der Doublewrite-Seite abgeschlossen ist, wird die Seite im Doublewrite-Puffer in jede Tablespace-Datei geschrieben. Zu diesem Zeitpunkt erfolgt das Schreiben diskret.

Sie können den Doppelschreibvorgang beobachten, indem Sie den folgenden Befehl ausführen: show global status like 'innodb_dblwr%'\G

Doublewrite schreibt insgesamt 18.445 Seiten, aber die tatsächliche Anzahl der Schreibvorgänge beträgt 434 (42:1), was im Wesentlichen mit 64:1 übereinstimmt.

Wenn Sie feststellen, dass Innodb_dblwr_pages_written:Innodb_dblwr_writes während der Spitzenzeiten deutlich unter 64:1 liegt, bedeutet dies, dass der Schreibdruck auf Ihrem System nicht sehr hoch ist.

Wenn das Betriebssystem beim Schreiben der Seite auf die Festplatte abstürzt, kann die InnoDB-Speicher-Engine während des Wiederherstellungsprozesses eine Kopie der geänderten Seite aus dem Doublewrite im gemeinsam genutzten Tablespace finden , sie in die Tablespace-Datei kopieren und dann das Redo-Protokoll anwenden . Nachfolgend sehen Sie einen Fall der Wiederherstellung durch Doublewrite:

090924 11:36:32 mysqld neu gestartet
090924 11:36:33 InnoDB: Datenbank wurde nicht normal heruntergefahren!
InnoDB: Absturzwiederherstellung wird gestartet.
InnoDB: Tablespace-Informationen aus den .ibd-Dateien lesen……
InnoDB: Fehler: Space-ID im FSP-Header 0, aber im Seitenheader 4294967295
InnoDB: Fehler: Tablespace-ID 4294967295 in Datei ./test/t.ibd ist nicht sinnvoll
InnoDB: Fehler: Tablespace-ID 0 in Datei ./test/t2.ibd ist nicht sinnvoll
090924 11:36:33 InnoDB: Betriebssystemfehler Nummer 40 bei einer Dateioperation.
InnoDB: Fehlernummer 40 bedeutet „Zu viele Ebenen symbolischer Links“.
InnoDB: Einige Fehlernummern des Betriebssystems werden beschrieben unter
InnoDB: http://dev.mysql.com/doc/refman/5.0/en/operating-system-error-codes.html
InnoDB: Dateiname./jetzt/Mitglied
InnoDB: Dateioperationsaufruf: „stat“.
InnoDB: Fehler: os_file_readdir_next_file() hat -1 zurückgegeben in
InnoDB: Verzeichnis./jetzt
InnoDB: Die Wiederherstellung nach einem Absturz ist möglicherweise für einige.ibd-Dateien fehlgeschlagen!
InnoDB: Wiederherstellen möglicher halbgeschriebener Datenseiten aus dem Doublewrite
InnoDB: Puffer…

Der Parameter skip_innodb_doublewrite kann die Doppelschreibfunktion deaktivieren, was das oben erwähnte Schreibfehlerproblem verursachen kann. Wenn Sie jedoch über mehrere Slave-Server verfügen und eine schnellere Leistung bereitstellen müssen (z. B. RAID0 auf den Slaves), ist das Aktivieren dieses Parameters möglicherweise eine Lösung. Auf dem Masterserver, der eine hohe Datenzuverlässigkeit gewährleisten muss, sollten wir jedoch immer sicherstellen, dass die Doppelschreibfunktion aktiviert ist.

Hinweis: Einige Dateisysteme verfügen über einen Mechanismus zur Vermeidung teilweiser Schreibfehler, z. B. das ZFS-Dateisystem. In diesem Fall sollten wir Doublewrite nicht aktivieren.

Adaptiver Hash-Index

Hash ist eine sehr schnelle Suchmethode und die Suchzeitkomplexität beträgt im Allgemeinen O(1). Wird häufig in Verknüpfungsvorgängen wie Hash-Verknüpfungen in SQL Server und Oracle verwendet. Gängige Datenbanken wie SQL Server und Oracle unterstützen jedoch keine Hash-Indizes. Der Standardindextyp der Heap-Speicher-Engine von MySQL ist Hash, während die InnoDB-Speicher-Engine eine andere Implementierungsmethode vorschlägt, den adaptiven Hash-Index.

Die InnoDB-Speicher-Engine überwacht die Suche nach Indizes in der Tabelle . Wenn sie feststellt, dass das Erstellen eines Hash-Index die Geschwindigkeit verbessern kann, erstellt sie einen Hash-Index. Dies wird als adaptiv bezeichnet. Der adaptive Hash-Index wird aus dem B+-Baum des Pufferpools erstellt und ist daher sehr schnell aufgebaut. Und es ist nicht notwendig, einen Hash-Index für die gesamte Tabelle zu erstellen. Die InnoDB-Speicher-Engine erstellt automatisch Hash-Indizes für bestimmte Seiten basierend auf der Zugriffshäufigkeit und dem Zugriffsmuster .

Laut der offiziellen Dokumentation von InnoDB können nach der Aktivierung des adaptiven Hash-Index die Lese- und Schreibgeschwindigkeiten um das Zweifache und bei den Verbindungsvorgängen des Hilfsindex die Leistung um das Fünffache gesteigert werden. Der adaptive Hash-Index stellt einen sehr guten Optimierungsmodus dar. Sein Designkonzept ist die Selbstoptimierung der Datenbank, was bedeutet, dass der DBA die Datenbank nicht anpassen muss.

Zeigen Sie die aktuelle Verwendung des adaptiven Hash-Index an: show engine innodb status\G

Jetzt können Sie die Nutzungsinformationen des adaptiven Hash-Index sehen, einschließlich der Größe des adaptiven Hash-Index, der Nutzung und der Anzahl der adaptiven Hash-Index-Suchen pro Sekunde. Beachten Sie, dass Hash-Indizes nur für die Suche nach gleichen Werten verwendet werden können, z. B. „select * from table where index_col='xxx'“, und nicht für andere Suchtypen, z. B. Bereichssuchen. Daher finden hier Nicht-Hash-Suchen statt. Verwenden Sie den Befehl „Hash-Suchen: Nicht-Hash-Suchen“, um eine ungefähre Vorstellung von der Effizienz der Verwendung von Hash-Indizes zu erhalten.

Da der adaptive Hash-Index von der InnoDB-Speicher-Engine gesteuert wird, dienen die Informationen hier nur zu Referenzzwecken. Wir können diese Funktion jedoch über den Parameter innodb_adaptive_hash_index deaktivieren oder aktivieren, der standardmäßig aktiviert ist.

Der obige Artikel zu den Hauptfunktionen von InnoDB – Cache einfügen, zweimal schreiben und adaptiver Hash-Index – ist der gesamte Inhalt, den der Editor mit Ihnen teilt. Ich hoffe, er kann Ihnen als Referenz dienen. Ich hoffe auch, dass Sie 123WORDPRESS.COM unterstützen werden.