MySQL-Speicher-Engine: Der Unterschied zwischen myIsam und innodb

MySQL verfügt über mehrere Speicher-Engines, MyISAM und InnoDB sind zwei häufig verwendete. Hier sind einige grundlegende Konzepte zu diesen beiden Motoren (keine ausführliche Einführung).

MyISAM ist die Standardspeicher-Engine für MySQL. Sie basiert auf dem traditionellen ISAM-Typ und unterstützt die Volltextsuche, ist jedoch nicht transaktionssicher und unterstützt keine Fremdschlüssel. Jede MyISAM-Tabelle wird in drei Dateien gespeichert: Die FRM-Datei speichert die Tabellendefinition; die Datendatei ist MYD (MYData); die Indexdatei ist MYI (MYIndex).

InnoDB ist eine Transaktions-Engine, die Rollback, Absturzwiederherstellung, Parallelitätskontrolle für mehrere Versionen, ACID-Transaktionen und Sperren auf Zeilenebene unterstützt (die Zeilensperre der InnoDB-Tabelle ist nicht absolut. Wenn MySQL Wenn der Bereich zu gescannt werden kann, kann die InnoDB-Tabelle auch die gesamte Tabelle sperren (z. B. die SQL-Anweisung während des Like-Vorgangs) und eine sperrenfreie Lesemethode bereitstellen, die mit dem Oracle-Typ übereinstimmt. InnoDB speichert seine Tabellen und Indizes in einem Tablespace, der mehrere Dateien enthalten kann.

Kernunterschied

MyISAM ist nicht transaktionssicher, während InnoDB transaktionssicher ist.

Die Granularität der MyISAM-Sperre erfolgt auf Tabellenebene, während InnoDB Sperren auf Zeilenebene unterstützt.

MyISAM unterstützt den Volltexttypindex, InnoDB unterstützt jedoch keinen Volltextindex.

MyISAM ist relativ einfach und daher hinsichtlich der Effizienz besser als InnoDB. Kleine Anwendungen können die Verwendung von MyISAM in Betracht ziehen.

MyISAM-Tabellen werden als Dateien gespeichert. Die Verwendung von MyISAM-Speicher bei der plattformübergreifenden Datenübertragung erspart Ihnen viel Ärger.

InnoDB-Tabellen sind sicherer als MyISAM-Tabellen. Sie können nicht-transaktionale Tabellen in transaktionale Tabellen umwandeln (alter table tablename type=innodb) und dabei sicherstellen, dass keine Daten verloren gehen.

Anwendungsszenarien

MyISAM verwaltet Nicht-Transaktionstabellen. Es bietet Hochgeschwindigkeitsspeicherung und -abruf sowie Volltextsuchfunktionen. Wenn Ihre Anwendung eine große Anzahl von SELECT-Abfragen ausführen muss, ist MyISAM die bessere Wahl.

InnoDB wird für Transaktionsverarbeitungsanwendungen verwendet und verfügt über zahlreiche Funktionen, einschließlich ACID-Transaktionsunterstützung. Wenn Ihre Anwendung eine große Anzahl von INSERT- oder UPDATE-Vorgängen ausführen muss, sollten Sie InnoDB verwenden, was die Leistung gleichzeitiger Mehrbenutzer-Vorgänge verbessern kann.

MySQL-Speicher-Engine und -Index

Die Datenbank muss einen Index haben. Ohne einen Index wird der Abrufprozess zu einer sequentiellen Suche. ist fast unerträglich. Man kann sich sehr leicht vorstellen, wie eine Tabelle, die nur aus einem einzigen Schlüssel besteht, mithilfe eines B+-Baums indiziert werden kann, solange der Schlüssel im Knoten des Baums gespeichert ist. Wenn ein Datenbankeintrag mehrere Felder enthält, kann ein B+-Baum nur den Primärschlüssel speichern. Wenn ein Nicht-Primärschlüsselfeld abgerufen wird, verliert der Primärschlüsselindex seine Funktion und wird wieder zu einer sequentiellen Suche. Zu diesem Zeitpunkt sollte ein zweiter Satz von Indizes für die zweite abzurufende Spalte erstellt werden. Dieser Index wird durch unabhängige B+-Bäume organisiert. Es gibt zwei gängige Methoden, um das Problem zu lösen, dass mehrere B+-Bäume auf denselben Satz von Tabellendaten zugreifen: Eine wird als Clustered-Index (Clustered-Index) und die andere als Nicht-Clustered-Index (Sekundärindex) bezeichnet. Obwohl diese beiden Namen als Indizes bezeichnet werden, handelt es sich nicht um einen separaten Indextyp, sondern um eine Datenspeichermethode. Bei der Clustered-Index-Speicherung werden Zeilendaten und Primärschlüssel-B+-Bäume zusammen gespeichert, und Sekundärschlüssel-B+-Bäume speichern nur Sekundärschlüssel und Primärschlüssel- und Nicht-Primärschlüssel-B+-Bäume sind fast zwei Arten von Bäumen. Für die nicht gruppierte Indexspeicherung speichert der Primärschlüssel-B+-Baum Zeiger auf die tatsächlichen Datenzeilen in Blattknoten anstelle des Primärschlüssels.

InnoDB verwendet einen Clustered-Index, um den Primärschlüssel in einem B+-Baum zu organisieren, und die Zeilendaten werden auf dem Blattknoten gespeichert. Wenn Sie die Bedingung „wobei id = 14“ verwenden, um den Primärschlüssel zu finden, befolgen Sie die folgenden Schritte Der B+-Baum-Abrufalgorithmus kann den entsprechenden Blattknoten finden und dann die Zeilendaten abrufen. Wenn Sie eine bedingte Suche in der Spalte „Name“ durchführen, sind zwei Schritte erforderlich: Der erste Schritt besteht darin, den Namen im Hilfsindex-B+-Baum abzurufen und seinen Blattknoten zu erreichen, um den entsprechenden Primärschlüssel zu erhalten. Der zweite Schritt verwendet den Primärschlüssel, um eine weitere B+-Baum-Abrufoperation für die primäre Index-B+-Baumart durchzuführen und schließlich den Blattknoten zu erreichen, um die gesamte Datenzeile zu erhalten.

MyISM verwendet einen nicht gruppierten Index. Die beiden B+-Bäume des nicht gruppierten Index sehen genau gleich aus, aber der gespeicherte Inhalt ist unterschiedlich Der Index-B+-Baum speichert den Primärschlüssel. Der Sekundärschlüssel-Index-B+-Baum speichert Sekundärschlüssel. Die Tabellendaten werden an einem separaten Ort gespeichert. Die Blattknoten der beiden B+-Bäume verwenden eine Adresse, um auf die tatsächlichen Tabellendaten zu verweisen. Es gibt keinen Unterschied zwischen den beiden Schlüsseln. Da die Indexbäume unabhängig sind, erfordert der Abruf durch Sekundärschlüssel keinen Zugriff auf den Indexbaum für den Primärschlüssel.

Um den Unterschied zwischen diesen beiden Indizes anschaulicher zu veranschaulichen, stellen wir uns eine Tabelle vor, die 4 Datenzeilen speichert, wie unten gezeigt. Dabei dient Id als primärer Index und Name als sekundärer Index. Das Diagramm zeigt deutlich den Unterschied zwischen Clustered-Index und Non-Clustered-Index.

Wir konzentrieren uns auf den Clustered-Index. Es scheint, dass die Effizienz des Clustered-Index offensichtlich geringer ist als die des Nicht-Clustered-Index, da jeder Abruf den Hilfsindex verwendet Muss die B+-Baumsuche zweimal durchgeführt werden, ist das nicht unnötig? Was sind die Vorteile des Clustered-Index?

1 Da die Zeilendaten und Blattknoten zusammen gespeichert werden, werden der Primärschlüssel und die Zeilendaten zusammen in den Speicher geladen. Wenn der Blattknoten gefunden wird, können die Zeilendaten sofort zurückgegeben werden die Primärschlüssel-ID, die Daten werden schnell aktualisiert.

2 Der Hilfsindex verwendet den Primärschlüssel als „Zeiger“ anstelle des Adresswerts als Zeiger. Der Vorteil besteht darin, dass der Wartungsaufwand des Hilfsindex reduziert wird, wenn eine Zeilenverschiebung oder eine Datenseitenaufteilung auftritt Durch die Verwendung des Primärschlüsselwerts als Zeiger nimmt der Hilfsindex mehr Platz ein. Der Vorteil besteht darin, dass InnoDB beim Verschieben von Zeilen den „Zeiger“ im Hilfsindex nicht aktualisieren muss. Das heißt, die Position der Zeile (die sich in der Implementierung über die 16K-Seite befindet, die später behandelt wird) ändert sich, wenn die Daten in der Datenbank geändert werden (die vorherige Aufteilung des B+-Baumknotens und die Seitenaufteilung) und Sie können einen Clustered-Index verwenden. Es ist garantiert, dass der Hilfsindexbaum unabhängig davon, wie sich die Knoten des Primärschlüssel-B+-Baums ändern, nicht beeinträchtigt wird.

Bei Millionen von Daten und größeren Datenmengen ist die Indexleistung von MySQL innoDB also noch besser!

Das obige ist der detaillierte Inhalt vonMySQL-Speicher-Engine: Der Unterschied zwischen myIsam und innodb. Für weitere Informationen folgen Sie bitte anderen verwandten Artikeln auf der PHP chinesischen Website!