MYSQL_Mehrversions-Parallelitätskontrolle, Speicher-Engine, Indexeinführung

Mehrversions-Parallelitätskontrolle

Die meisten Transaktionsspeicher-Engines von MySQL implementieren keine einfachen Sperren auf Zeilenebene. Basierend auf der Überlegung, die Parallelitätsleistung zu verbessern, implementieren sie im Allgemeinen gleichzeitig die Parallelitätskontrolle für mehrere Versionen.

MVCC kann als Variante der Sperrung auf Zeilenebene angesehen werden, vermeidet jedoch in vielen Fällen Sperrvorgänge, da der Overhead geringer ist.

InnoDBs MVCC wird durch zwei versteckte Spalten implementiert, die am Ende jedes Zeilendatensatzes gespeichert werden. Eine dieser beiden Spalten speichert die Erstellungszeit der Zeile und die andere die Ablaufzeit (oder Löschzeit). In der Zeile wird natürlich nicht der tatsächliche Zeitwert, sondern die Systemversion gespeichert. Bei jedem Start einer neuen Transaktion wird die Systemversionsnummer automatisch erhöht. Die Systemversionsnummer zu Beginn der Transaktion wird als Versionsnummer der Transaktion verwendet, mit der die Versionsnummern jeder abgefragten Zeile verglichen werden.

Unter der Isolationsstufe REPEATABLE READ ist die Implementierung von MVCC:

• SELECT

• Die Suchversion von InnoDB ist älter als die Datenzeile der aktuellen Transaktionsversionsnummer. Dadurch wird sichergestellt, dass die von der Transaktion gelesenen Zeilen entweder bereits vor dem Start der Transaktion vorhanden sind oder von der Transaktion selbst eingefügt oder geändert wurden. Die gelöschte Version der Zeile

• ist entweder undefiniert oder größer als die aktuelle Transaktionsversionsnummer. Dadurch wird sichergestellt, dass die von der Transaktion gelesene Zeile nicht vor Beginn der Transaktion gelöscht wurde.

• INSERT

• InnoDB speichert die aktuelle Systemversionsnummer als Zeilenversionsnummer für jede neu eingefügte Zeile.

• DELETE

• InnoDB speichert die aktuelle Systemversionsnummer als Zeilenlöschungskennung für jede gelöschte Zeile.

• UPDATE

• InnoDB speichert die aktuelle Systemversionsnummer als Zeilenversionsnummer zum Einfügen eines neuen Datensatzes der Fluggesellschaft Eins und gleichzeitig Speichern Sie die aktuelle Systemversionsnummer in der ursprünglichen Zeile als Zeilenlöschversionsnummer.

MVCC funktioniert nur auf zwei Isolationsstufen: REPEATABLE READ und READ COMMITED. Die anderen beiden Isolationsstufen sind nicht mit MVCC kompatibel. Da READ UNCOMMITED immer die neueste Datenzeile liest, nicht die Datenzeile, die der aktuellen Transaktionsversion entspricht. SERIALIZABLE sperrt alle gelesenen Datenzeilen.

Speicher-Engine

InnoDB-Speicher-Engine

InnoDB ist die Standard-Transaktions-Engine von MYSQL und auch die am häufigsten verwendete Wichtig und am häufigsten verwendet. Sofern kein ganz besonderer Grund vorliegt, eine andere Speicher-Engine zu verwenden, sollte der InnoDB-Engine Vorrang eingeräumt werden.

InnoDB verwendet MVCC zur Unterstützung hoher Parallelität und implementiert vier Standardisolationsstufen. Die Standardstufe ist REPEATABLE READ, und die Lückensperre + MVCC-Strategie verhindert Phantom-Lesevorgänge. Mit der Lückensperre kann InnoDB nicht nur die Zeilen des Abfrageentwurfs sperren, sondern auch die Lücken im Index, um das Einfügen von Phantomzeilen zu verhindern.

Lückensperre: Wenn wir Bereichsbedingungen anstelle von Gleichheitsbedingungen verwenden, um Daten abzurufen und gemeinsame oder exklusive Sperren anzufordern, sperrt InnoDB die Indexeinträge vorhandener Datensätze, die die Bedingungen für Schlüsselwerte erfüllen In der Bedingung werden Datensätze, die innerhalb des Bereichs liegen, aber nicht vorhanden sind, als „Lücke“ bezeichnet. Dieser Sperrmechanismus ist die sogenannte Lückensperre (Next-Key-Sperre).
Referenz: Gap Lock (Next-Key Lock)

Der Hauptindex ist ein Clustered-Index, der Daten im Index speichert, um ein direktes Lesen von der Festplatte zu vermeiden, wodurch die Abfrageleistung erheblich verbessert wird.

InnoDB hat viele interne Optimierungen vorgenommen, darunter vorhersehbares Vorauslesen beim Lesen von Daten von der Festplatte, einen adaptiven Hash-Index, der automatisch einen Hash-Index im Speicher erstellen kann, um Vorgänge zu beschleunigen, und eine Möglichkeit, Einfügungen zu beschleunigen. Operationen Puffer einfügen usw.

MyISAM-Speicher-Engine

In mysql5.1 und früheren Versionen ist MyISAM die Standard-Speicher-Engine. MyISAM bietet eine große Anzahl von Funktionen, darunter Volltextindizierung, Komprimierung, räumliche Funktionen usw., unterstützt jedoch keine Transaktionen und Sperren auf Zeilenebene und weist zweifellos den Fehler auf, dass es nach einem Absturz nicht sicher wiederhergestellt werden kann.

Für schreibgeschützte Daten oder wenn die Tabelle relativ klein ist und Reparaturvorgänge tolerieren kann, kann die MyISAM-Engine weiterhin verwendet werden.

Wenn beim Erstellen einer MyISAM-Tabelle die Option DELAY_KEY_WRITE angegeben ist, werden die geänderten Indexdaten nach Abschluss jeder Änderung nicht sofort auf die Festplatte, sondern in den entsprechenden Schlüsselpuffer geschrieben Der Indexblock wird nur auf die Festplatte geschrieben, wenn der Schlüsselpuffer gelöscht oder die Tabelle geschlossen wird. Diese Methode kann die Schreibleistung erheblich verbessern, führt jedoch zu Indexschäden, wenn die Datenbank oder der Host abstürzt, was Reparaturvorgänge erforderlich macht.

Vergleiche

• Transaktion: InnoDB unterstützt Transaktionen, MyISAM unterstützt keine Transaktionen.

• Sperrgranularität: InnoDB unterstützt Sperren auf Tabellenebene und Sperren auf Zeilenebene, während MyISAM nur Sperren auf Tabellenebene unterstützt.

• Fremdschlüssel: InnoDB unterstützt Fremdschlüssel.

• Backup: InnoDB unterstützt Hot-Backup, es sind jedoch Tools erforderlich.

• Absturzwiederherstellung: Die Wahrscheinlichkeit eines Schadens nach einem Absturz von MyISAM ist viel höher als bei InnoDB, und die Wiederherstellungsgeschwindigkeit ist auch langsamer.

• Weitere Funktionen: MyISAM unterstützt Volltextindizierung, Komprimierung, räumliche Funktionen und andere Funktionen.

Sicherungstyp

• Kaltsicherung: Der MySQL-Dienst muss ausgeschaltet sein und Lese- und Schreibanfragen sind nicht zulässig;

• Warm-Backup: Der Dienst ist online, unterstützt jedoch nur Leseanfragen und lässt keine Schreibanfragen zu wird nicht beeinträchtigt.

• Index

Indizes (auch „Schlüssel“ genannt) werden von Speicher-Engines verwendet, um Datensätze A schnell zu finden Struktur in . B-Tree-Index

Die meisten MySQL-Engines unterstützen diesen Index.

Obwohl der Begriff „B-Tree“ verwendet wird, können verschiedene Speicher-Engines unterschiedliche Speicherstrukturen verwenden. Die NDB-Cluster-Speicher-Engine verwendet tatsächlich T-Tree intern, während InnoDB B+Tree verwendet.

Der B-Tree-Index kann den Datenzugriff beschleunigen, da die Speicher-Engine keinen vollständigen Tabellenscan durchführen muss, um die erforderlichen Daten zu erhalten. Stattdessen beginnt sie mit der Suche vom Stammknoten des Index aus Geschwindigkeit wird viel schneller sein.

B-Tree organisiert und speichert Indexspalten nacheinander, was sich sehr gut für die Suche nach Bereichsdaten eignet. Da der Indexbaum geordnet ist, kann er neben der Benutzersuche auch zum Sortieren und Gruppieren verwendet werden.

Sie können mehrere Spalten als Indexspalten angeben und mehrere Indexspalten bilden zusammen einen Indexschlüssel. Der B-Tree-Index eignet sich für die Suche nach vollständigen Schlüsselwerten, Schlüsselwertbereichen oder Schlüsselpräfixen, wobei die Suche nach Schlüsselpräfixen nur auf die Suche basierend auf dem Präfix ganz links anwendbar ist. Die Suche muss in der Spalte ganz links im Index beginnen.

Datenstruktur des B-Tree-Index

B-Tree

Um den B-Tree zu beschreiben, definieren Sie ihn zunächst Ein Datenelement ist ein Tupel [Schlüssel, Daten]. Bei verschiedenen Datensätzen sind die Daten die Daten im Datensatz, mit Ausnahme des Schlüssels.

Alle Knoten haben die gleiche Tiefe, was bedeutet, dass der B-Baum ausgeglichen ist.

• Die Schlüssel in einem Knoten sind von links nach rechts nicht abnehmend angeordnet.

• Wenn die linken und rechten benachbarten Schlüssel eines Zeigers keyi bzw. keyi+1 sind und nicht null sind, dann sind alle Schlüssel, auf die der Zeiger zeigt, größer oder gleich keyi und kleiner oder gleich keyi+ 1.

• Suchalgorithmus: Führen Sie zunächst eine binäre Suche auf dem Wurzelknoten durch. Wenn gefunden, geben Sie die Daten des entsprechenden Knotens zurück, auf den der Zeiger zeigt entsprechendes Intervall.
  Da das Einfügen und Löschen neuer Datensätze die Eigenschaften von B-Tree zerstört, muss der Baum beim Einfügen und Löschen geteilt, zusammengeführt, gedreht usw. werden, um die Eigenschaften von B-Tree beizubehalten.

B+Tree

Im Vergleich zu B-Tree weist B+Tree die folgenden Eigenschaften auf:

Die Obergrenze des Zeigers jedes Knotens beträgt 2d statt 2d+1 (d ist der Grad des B-Baums).

• Interne Knoten speichern keine Daten, nur externe Knoten speichern keine Zeiger.

B+Tree mit sequentiellen Zugriffszeigern

Im Allgemeinen in einem Datenbanksystem oder Dateisystem Der B Die verwendeten +Tree-Strukturen werden auf Basis des klassischen B+Tree optimiert und es werden sequentielle Zugriffszeiger hinzugefügt.

Der Zweck dieser Optimierung besteht darin, eine Intervallzugriffsleistung bereitzustellen, wenn Sie beispielsweise alle Datensätze mit den Schlüsseln 18 bis 49 in der Abbildung abfragen möchten.

Vorteile

Ausbalancierte Bäume wie Rot-Schwarz-Bäume können ebenfalls zur Implementierung von Indizes verwendet werden, Dateisysteme und Datenbanksysteme verwenden jedoch im Allgemeinen B-Tree als Indexstruktur Die wichtigsten sind die folgenden Zwei Gründe:

Bessere Abrufzeiten: Die zeitliche Komplexität des Abrufs von Daten in einem ausgeglichenen Baum entspricht ungefähr der Baumhöhe h O(h) = O(logN), wobei d der Out-Grad jedes Knotens ist. Der Out-Grad des Rot-Schwarz-Baums beträgt 2, während der Out-Grad des B-Baums im Allgemeinen sehr groß ist. Die Baumhöhe h des Rot-Schwarz-Baums ist offensichtlich viel höher als die des B-Baums. Daher ist die Anzahl der Suchanfragen höher. B+Tree eignet sich besser für externe Speicherindizes als B-Tree, da das Datenfeld von den Knoten in B+Tree entfernt wird, sodass es einen größeren Out-Grad haben kann und die Abrufeffizienz höher ist.

• Verwenden von Computer-Read-Ahead-Funktionen: Um den Festplatten-I/O-Vorgang zu reduzieren, lesen Festplatten oft nicht ausschließlich bei Bedarf, sondern jedes Mal im Voraus. Die theoretische Grundlage dafür ist das in der Informatik bekannte Lokalitätsprinzip: Bei der Nutzung eines Datenstücks werden in der Regel unmittelbar benachbarte Daten genutzt. Während des Lesevorgangs wird die Festplatte sequentiell gelesen. Das sequentielle Lesen erfordert keine Festplattensuche und erfordert nur eine kurze Rotationszeit, sodass die Geschwindigkeit sehr hoch ist. Das Betriebssystem unterteilt den Speicher und die Festplatte im Allgemeinen in Blöcke fester Größe, jeder Block wird als Seite bezeichnet und der Speicher und die Festplatte tauschen Daten in Seiteneinheiten aus. Das Datenbanksystem legt die Größe eines Knotens im Index auf die Größe der Seite fest, sodass ein Knoten in einer E/A vollständig geladen werden kann und benachbarte Knoten auch mithilfe der Read-Ahead-Funktion vorgeladen werden können.

Referenz: Datenstruktur und Algorithmusprinzipien hinter MySQL-Indizes

Hash-Index

Die InnoDB-Engine verfügt über eine spezielle Funktion namens „ „Adaptive“. „Hash-Index“: Wenn ein Indexwert sehr häufig verwendet wird, wird ein Hash-Index über dem B+Tree-Index erstellt, sodass der B+Tree-Index einige Vorteile des Hash-Index bietet, wie z. B. eine schnelle Hash-Suche.

Hash-Index kann in O(1)-Zeit durchsucht werden, aber es verliert an Ordnung. Es gibt die folgenden Einschränkungen:

• Hash-Index enthält nur Hashes. Der Wert folgt dem Der Zeilenzeiger ist ein Zeilenzeiger und speichert den Feldwert nicht. Daher können Sie den Wert im Index nicht verwenden, um das Löschen der Zeile zu vermeiden.

• kann nicht zum Sortieren und Gruppieren verwendet werden.

• unterstützt nur die präzise Suche und kann nicht für Teilsuche und Bereichssuche verwendet werden.

• Wenn eine Hash-Kollision auftritt, muss die Speicher-Engine alle Zeilenzeiger in der verknüpften Liste durchlaufen.

Räumlicher Datenindex (R-Baum)

Die MyISAM-Tabelle unterstützt den räumlichen Index und kann als geografischer Datenspeicher verwendet werden. Räumliche Indizes indizieren Daten aus allen Dimensionen, und Abfragen können basierend auf jeder Dimension kombiniert werden.

Die GIS-bezogenen Funktionen von MySQL wie MBRONTAINS() müssen zur Datenpflege verwendet werden.

Volltextindex

Der Volltextindex ist ein spezieller Indextyp, der nach Schlüsselwörtern im Text sucht, anstatt Werte im Index direkt zu vergleichen. Die Suchbedingung verwendet MATCH AGAINST statt einfach WHERE.

Der Volltextindex wird im Allgemeinen mithilfe eines invertiert sortierten Index implementiert, der die Zuordnung des Dokuments aufzeichnet, bei dem das Schlüsselwort abläuft.

Die MyISAM-Speicher-Engine unterstützt die Volltextindizierung und die InnoDB-Speicher-Engine unterstützt auch die Volltextindizierung in Mysql 5.6.4.

Vorteile von Indizes

• Reduzieren Sie die Anzahl der Datenzeilen, die der Server scannen muss, erheblich.

• Hilft dem Server, das Sortieren und Erstellen temporärer Tabellen zu vermeiden (B+Tree-Indizes sind geordnet und können für „Sortieren nach“- und „Gruppieren nach“-Vorgänge verwendet werden).

• Zufällige E/A in sequentielle E/A umwandeln (B+Tree-Index ist geordnet, d. h. benachbarte Daten werden zusammen gespeichert).

Verwandte Artikel:

Analyse des Implementierungsprinzips der InnoDB Storage Engine Multi-Version Control (MVCC) in der MySQL-Datenbank

Einführung in die MySQL-Speicher-Engine

Das obige ist der detaillierte Inhalt vonMYSQL_Mehrversions-Parallelitätskontrolle, Speicher-Engine, Indexeinführung. Für weitere Informationen folgen Sie bitte anderen verwandten Artikeln auf der PHP chinesischen Website!