MySQL-Architektur

Sehen Sie sich das erste Kapitel der MySQL-Architektur und die Geschichte von „High Performance MySQL“ an

1.1 MySQL Logical Architecture

Referenz

Abbildung 1-1: Diagramm der logischen Architektur des MySQL-Servers

Die Top-Level-Dienste gibt es nicht nur bei MySQL, die meisten sind netzwerkbasiert Client/Server-Tools oder -Dienste haben eine ähnliche Architektur. Wie Verbindungsverarbeitung, Autorisierungsauthentifizierung, Sicherheit usw.

Die Second-Layer-Architektur ist der interessantere Teil von MySQL. Die meisten Kerndienstfunktionen von MySQL befinden sich in dieser Ebene, einschließlich Abfrageanalyse, Analyse, Optimierung, Caching und allen integrierten Funktionen (z. B. Datum, Uhrzeit, Mathematik und Verschlüsselungsfunktionen). Alle speicherübergreifenden Engine-Funktionen befinden sich in dieser Ebene Schichtimplementierung: gespeicherte Prozeduren, Trigger, Ansichten usw.

Die dritte Schicht enthält die Speicher-Engine. Die Speicher-Engine ist für das Speichern und Abrufen von Daten in MySQL verantwortlich. Wie verschiedene Dateisysteme unter GNU/Linux hat jede Speicher-Engine ihre Vor- und Nachteile. Der Server kommuniziert über APIs mit der Speicher-Engine. Diese Schnittstellen schirmen die Unterschiede zwischen verschiedenen Speicher-Engines ab und machen diese Unterschiede für den Abfrageprozess der oberen Ebene transparent. Die Storage-Engine-API enthält Dutzende Low-Level-Funktionen zum Ausführen von Vorgängen wie „Starten einer Transaktion“ oder „Extrahieren einer Datensatzzeile basierend auf dem Primärschlüssel“. Die Speicher-Engine analysiert jedoch kein SQL und verschiedene Speicher-Engines kommunizieren nicht miteinander, sondern reagieren lediglich auf die Anfrage des übergeordneten Servers.

1.2 Parallelitätskontrolle

1.2.1 Lese-/Schreibsperre

Diese beiden Arten von Sperren werden normalerweise als gemeinsame Sperren und exklusive Sperren bezeichnet, auch Lesesperre (Lesesperre) genannt. und Schreibsperre (Schreibsperre). Lesesperren sind gemeinsam genutzt oder nicht blockierend. Mehrere Clients können gleichzeitig dieselbe Ressource lesen, ohne sich gegenseitig zu stören. Schreibsperren sind exklusiv, das heißt, eine Schreibsperre blockiert andere Schreibsperren und Lesesperren.

1.2.2 Sperrgranularität

Die beiden wichtigsten Sperrstrategien: Tabellensperre und Sperre auf Zeilenebene

Tabellensperre (Tabellensperre)

Tabelle Sperren sind die grundlegendste Sperrstrategie in MySQL und die kostengünstigste Strategie. Dadurch wird die gesamte Tabelle gesperrt. Bevor ein Benutzer Schreibvorgänge (Einfügen, Löschen, Aktualisieren usw.) für die Tabelle ausführen kann, muss er eine Schreibsperre erhalten, die alle Lese- und Schreibvorgänge anderer Benutzer für die Tabelle blockiert. Nur wenn keine Schreibsperre vorhanden ist, können andere lesende Benutzer die Lesesperre erhalten und Lesesperren blockieren sich nicht gegenseitig.

Tabellensperren können in bestimmten Szenarien auch eine gute Leistung erbringen. Beispielsweise unterstützen READ LOCAL-Tabellensperren bestimmte Arten gleichzeitiger Schreibvorgänge. Darüber hinaus haben Schreibsperren auch eine höhere Priorität als Lesesperren, sodass eine Schreibsperranforderung vor der Lesesperrenwarteschlange eingefügt werden kann (eine Schreibsperre kann vor einer Lesesperre in die Sperrwarteschlange eingefügt werden, während eine Lesesperre vor einer Lesesperre eingefügt werden kann (Schreibsperre kann nicht eingesetzt werden) an der Vorderseite der Schreibsperre).

Sperre auf Zeilenebene (Zeilensperre)

Sperre auf Zeilenebene kann die gleichzeitige Verarbeitung weitestgehend unterstützen (bringt aber auch den größten Sperraufwand mit sich). Wie wir alle wissen, ist das Sperren auf Zeilenebene in InnoDB und XtraDB sowie einigen anderen Speicher-Engines implementiert. Sperren auf Zeilenebene werden nur auf der Ebene der Speicher-Engine implementiert, nicht jedoch auf der Ebene des MySQL-Servers. Die Serverschicht hat keine Kenntnis von der Sperrimplementierung in der Speicher-Engine.

1.3 Transaktionen

Transaktionen unterstützen die ACID-Prinzipien.

Atomizität

Eine Transaktion muss als unteilbare Mindestarbeitseinheit betrachtet werden.

Konsistenz

Die Datenbank wechselt immer von einem konsistenten Zustand in einen anderen konsistenten Zustand.

Isolierung

Im Allgemeinen sind von einer Transaktion vorgenommene Änderungen für andere Transaktionen nicht sichtbar, bevor sie endgültig festgeschrieben werden.

Dauerhaftigkeit

Sobald eine Transaktion festgeschrieben wurde, werden ihre Änderungen dauerhaft in der Datenbank gespeichert.

1.3.1 Isolationsstufe

Im Folgenden finden Sie eine kurze Einführung in die vier Isolationsstufen.

READ UNCOMMITTED (nicht festgeschriebenes Lesen)

Auf der Ebene READ UNCOMMITTED sind Änderungen in einer Transaktion für andere Transaktionen sichtbar, auch wenn sie nicht festgeschrieben sind. Transaktionen können nicht festgeschriebene Daten lesen, was auch als Dirty Read bezeichnet wird. In Bezug auf die Leistung kann READ UNCOMMITTED nicht viel besser sein als andere Ebenen, es fehlen jedoch viele Vorteile anderer Ebenen, es sei denn, es gibt wirklich notwendige Gründe. .

engagiert lesen

Die Standardisolationsstufe der meisten Datenbanksysteme ist READ COMMITTED (jedoch nicht MySQL). Alle von einer Transaktion vom Anfang bis zum Commit vorgenommenen Änderungen sind für andere Transaktionen nicht sichtbar. Diese Ebene wird manchmal als nicht wiederholbares Lesen bezeichnet, da die zweimalige Ausführung derselben Abfrage zu unterschiedlichen Ergebnissen führen kann.

REPEATABLE READ (wiederholbares Lesen)

　 REPEATABLE READ löst das Problem des schmutzigen Lesens. Auf dieser Ebene wird sichergestellt, dass die Ergebnisse beim mehrmaligen Lesen desselben Datensatzes in derselben Transaktion konsistent sind. Theoretisch kann die wiederholbare Leseisolationsstufe jedoch immer noch kein anderes Phantomleseproblem (Phantom Read) lösen. Der sogenannte Phantom-Leser bedeutet, dass eine andere Transaktion einen neuen Datensatz in den Bereich einfügt, wenn eine Transaktion Datensätze in einem bestimmten Bereich liest. Wenn die vorherige Transaktion die Datensätze in dem Bereich erneut liest, erzeugt sie eine Phantomzeile. InnoDB- und XtraDB-Speicher-Engines lösen das Problem von Phantom-Lesevorgängen durch Multiversion Concurrency Control (MVCC).

Wiederholbares Lesen ist die Standard-Transaktionsisolationsstufe von MySQL.

SERIALIZABLE (serialisierbar)

SERIALIZABLE ist die höchste Isolationsstufe. Es vermeidet das zuvor erwähnte Phantomleseproblem, indem es die serielle Ausführung von Transaktionen erzwingt. Einfach ausgedrückt sperrt SERIALIZABLE jede abgerufene Datenzeile, was zu vielen Zeitüberschreitungen und Sperrkonfliktproblemen führen kann. Diese Isolationsstufe wird in tatsächlichen Anwendungen selten verwendet. Diese Stufe sollte nur in Betracht gezogen werden, wenn die Datenkonsistenz unbedingt gewährleistet sein muss und keine Parallelität akzeptabel ist.

1.3.2 Deadlock

Deadlock bezieht sich auf zwei oder mehr Transaktionen, die sich gegenseitig auf derselben Ressource belegen und anfordern, die voneinander belegten Ressourcen zu sperren, was zu The führt Phänomen des Teufelskreises. Deadlocks können auftreten, wenn mehrere Transaktionen versuchen, Ressourcen in unterschiedlicher Reihenfolge zu sperren. Ein Deadlock kann auch auftreten, wenn mehrere Transaktionen gleichzeitig dieselbe Ressource sperren.

Um dieses Problem zu lösen, implementiert das Datenbanksystem verschiedene Deadlock-Erkennungs- und Deadlock-Timeout-Mechanismen. Komplexere Systeme wie die InnoDB-Speicher-Engine sind besser in der Lage, zirkuläre Deadlock-Abhängigkeiten zu erkennen und sofort einen Fehler zurückzugeben. Diese Lösung ist sehr effektiv, da ein Deadlock andernfalls zu sehr langsamen Abfragen führt. Eine andere Lösung besteht darin, die Sperranforderung aufzugeben, wenn die Abfragezeit die Einstellung für das Sperrwartezeitlimit erreicht. Diese Methode ist im Allgemeinen nicht gut. Die aktuelle Methode von InnoDB zum Umgang mit Deadlocks besteht darin, die Transaktion mit der geringsten exklusiven Sperre auf Zeilenebene zurückzusetzen (dies ist ein relativ einfacher Deadlock-Rollback-Algorithmus).

Das Verhalten und die Reihenfolge von Sperren hängen mit der Speicher-Engine zusammen. Bei der Ausführung von Anweisungen in derselben Reihenfolge führen einige Speicher-Engines zu Deadlocks, andere jedoch nicht. Deadlocks treten aus zwei Gründen auf: Einige sind auf echte Datenkonflikte zurückzuführen, die oft schwer zu vermeiden sind, andere sind jedoch ausschließlich auf die Art und Weise zurückzuführen, wie die Speicher-Engine implementiert ist.

1.3.3 Transaktionsprotokoll

Wenn die Speicher-Engine mithilfe des Transaktionsprotokolls die Daten in der Tabelle ändert, muss sie nur ihre Speicherkopie ändern und dann die Änderung an der Transaktion aufzeichnen Protokoll, das auf der Festplatte gespeichert wird, anstatt jedes Mal die geänderten Daten selbst auf der Festplatte zu speichern. Das Transaktionsprotokoll wird angehängt. Nachdem das Transaktionsprotokoll beibehalten wurde, können die geänderten Daten im Speicher im Hintergrund langsam auf die Festplatte zurückgespült werden. Derzeit sind die meisten Speicher-Engines auf diese Weise implementiert, was wir normalerweise als Write-Ahead-Protokollierung (Write-Ahead-Protokollierung) bezeichnen. Das Ändern von Daten erfordert zweimaliges Schreiben auf die Festplatte.

Wenn die Datenänderung im Transaktionsprotokoll aufgezeichnet und beibehalten wurde, die Daten selbst jedoch nicht auf die Festplatte zurückgeschrieben wurden und das System abstürzt, kann die Speicher-Engine diese geänderten Daten beim Neustart automatisch wiederherstellen. Die spezifische Wiederherstellungsmethode hängt von der Speicher-Engine ab.

1.3.4 Transaktionen in MySQL

1.4 Multiversions-Parallelitätskontrolle

Die Implementierung von MVCC wird durch das Speichern einer Momentaufnahme der Daten zu einem bestimmten Zeitpunkt erreicht. Mit anderen Worten: Unabhängig davon, wie lange die Ausführung dauert, sind die von jeder Transaktion angezeigten Daten konsistent. Abhängig von der Zeit, zu der die Transaktion beginnt, können die Daten, die jede Transaktion zur gleichen Zeit in derselben Tabelle sieht, unterschiedlich sein. Im Folgenden veranschaulichen wir anhand einer vereinfachten Version des Verhaltens von InnoDB, wie MVCC funktioniert.

Der MVCC von InnoDB wird implementiert, indem zwei versteckte Spalten hinter jeder Datensatzzeile gespeichert werden. Von diesen beiden Spalten enthält eine die Erstellungszeit der Zeile und die andere die Ablaufzeit (oder Löschzeit) der Zeile. Gespeichert wird natürlich nicht der tatsächliche Zeitwert, sondern die Systemversionsnummer. Jedes Mal, wenn eine neue Transaktion gestartet wird, wird die Systemversionsnummer automatisch erhöht. Die Systemversionsnummer zu Beginn der Transaktion wird als Versionsnummer der Transaktion verwendet, die zum Vergleich mit der Versionsnummer jeder abgefragten Datensatzzeile verwendet wird. Werfen wir einen Blick darauf, wie MVCC speziell unter der Isolationsstufe REPEATABLE READ funktioniert.

SELECT

InnoDB prüft jede Zeile von Datensätzen basierend auf den folgenden zwei Bedingungen:

a. InnoDB sucht nur nach Datenzeilen, deren Version älter als die aktuelle Transaktionsversion ist (d. h. die Systemversionsnummer der Zeile ist kleiner oder gleich der Systemversionsnummer der Transaktion). Dadurch wird sichergestellt, dass die Zeilen von der Transaktion gelesen werden entweder bereits vor Beginn der Transaktion vorhanden oder durch die Transaktion selbst geändert.

b. Die gelöschte Version der Zeile ist entweder undefiniert oder größer als die aktuelle Transaktionsversionsnummer. Dadurch wird sichergestellt, dass die von der Transaktion gelesenen Zeilen nicht vor dem Start der Transaktion gelöscht wurden.

Nur ​​Datensätze, die die beiden oben genannten Bedingungen erfüllen, können als Abfrageergebnisse zurückgegeben werden.

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 fügt eine neue Zeile mit Datensätzen ein, speichert die aktuelle Systemversionsnummer als Zeilenversionsnummer und speichert die aktuelle Systemversionsnummer in der ursprünglichen Zeile als Zeilenlöschung Identifikator.

Speichern Sie diese beiden zusätzlichen Systemversionsnummern, damit die meisten Lesevorgänge ohne Sperren durchgeführt werden können. Dieses Design macht den Datenlesevorgang sehr einfach, die Leistung ist sehr gut und es stellt außerdem sicher, dass nur Zeilen gelesen werden, die den Standards entsprechen. Die Nachteile bestehen darin, dass jede Datensatzzeile zusätzlichen Speicherplatz, mehr Zeilenprüfung und einige zusätzliche Wartungsarbeiten erfordert.

MVCC funktioniert nur unter zwei Isolationsstufen: REPEATABLE READ und READ COMMITTED. Die anderen beiden Isolationsstufen sind nicht mit MVCC Note 4 kompatibel, da READ UNCOMMITTED immer die neueste Datenzeile liest, nicht die Datenzeile, die der aktuellen Transaktionsversion entspricht. SERIALIZABLE sperrt alle gelesenen Zeilen.

1.5 MySQL-Speicher-Engine

Im Dateisystem speichert MySQL jede Datenbank (auch Schema genannt) als Unterverzeichnis im Datenverzeichnis. Beim Erstellen einer Tabelle erstellt MySQL eine .frm-Datei mit demselben Namen wie die Tabelle im Datenbankunterverzeichnis, um die Tabellendefinition zu speichern. Wenn Sie beispielsweise eine Tabelle mit dem Namen MyTable erstellen, speichert MySQL die Definition der Tabelle in der Datei MyTable.frm. Da MySQL Dateisystemverzeichnisse und -dateien zum Speichern von Datenbank- und Tabellendefinitionen verwendet, hängt die Groß-/Kleinschreibung eng mit der jeweiligen Plattform zusammen. Unter Windows wird die Groß-/Kleinschreibung nicht beachtet; in Unix-ähnlichen Fällen wird die Groß-/Kleinschreibung beachtet. Verschiedene Speicher-Engines speichern Daten und Indizes auf unterschiedliche Weise, aber die Definition von Tabellen wird in der MySQL-Serviceschicht einheitlich gehandhabt.

Sie können den Befehl SHOW TABLE STATUS verwenden (in Versionen nach MySQL 5.0 können Sie auch die entsprechende Tabelle in INFORMATION SCHEMA abfragen), um tabellenbezogene Informationen anzuzeigen. Zum Beispiel für die Benutzertabelle in der MySQL-Datenbank:

mysql> SHOW TABLE STATUS LIKE 'user' G

Name: user

Engine: MyISAM

Zeilenformat: Dynamisch

Zeilen: 6

Durchschn._Zeilenlänge: 59

Datenlänge: 356

Maximale Datenlänge: 4294967295

Indexlänge: 2048

Datenfrei: 0

Automatische_Inkrementierung: NULL

Erstellungszeit: 24.01.2002 18:07:17

Aktualisierungszeit: 2002 - 01- 24 21: 56 : 29

Prüfzeit: NULL

Sortierung: ut f8_bin

Prüfsumme: NULL

Erstellungsoptionen:

Kommentar: Benutzer und globale Berechtigungen

1 Zeile im Satz (o.oo Sek.)

Die Ergebnisse zeigen, dass es sich um eine MyISAM-Tabelle handelt. Die Ausgabe enthält viele weitere Informationen sowie Statistiken. Nachfolgend finden Sie eine kurze Einführung in die Bedeutung jeder Zeile.

Name	Tabellenname.
Engine	Der Speicher-Engine-Typ der Tabelle. In älteren Versionen lautete der Name der Spalte „Typ“ und nicht „Engine“.
Zeilenformat	Zeilenformat. Für MyISAM-Tabellen sind die optionalen Werte Dynamic, Fixed oder Com ressed. Die Zeilenlänge von Dynamic ist variabel und enthält im Allgemeinen Felder variabler Länge, z. B. VARCHAR oder BLOB. Die feste Zeilenlänge ist fest und enthält nur Spalten fester Länge, wie z. B. CHAR und INTEGER. Komprimierte Zeilen gibt es nur in komprimierten Tabellen.
Zeilen	Die Anzahl der Zeilen in der Tabelle. Für MyISAM und einige andere Speicher-Engines ist der Wert präzise, ​​für InnoDB handelt es sich jedoch um eine Schätzung.
Avg_ row_length	Die durchschnittliche Anzahl von Bytes pro Zeile.
Datenlänge	Die Größe der Tabellendaten in Bytes.
Max- data_length	Die maximale Kapazität der Tabellendaten. Dieser Wert bezieht sich auf die Speicher-Engine.
Indexlänge	Die Größe des Index in Bytes.
Data_free	Stellt bei MyISAM-Tabellen zugewiesenen, aber derzeit ungenutzten Speicherplatz dar. Dieser Teil des Speicherplatzes umfasst zuvor gelöschte Zeilen und den Speicherplatz, der später von INSERT verwendet werden kann.
Auto_increment	Der Wert des nächsten AUTO INCREMENT.
Create_time	Die Erstellungszeit der Tabelle.
Update_time	Der letzte Änderungszeitpunkt der Tabellendaten.
Check_ time	Der Zeitpunkt, zu dem die Tabelle zuletzt mit dem Befehl CKECK TABLE oder dem Tool myisamchk überprüft wurde.
Sortierung	Der Standardzeichensatz und die Zeichenspaltensortierung für die Tabelle.
Prüfsumme	Wenn aktiviert, wird eine Echtzeit-Prüfsumme der gesamten Tabelle gespeichert.
Create_options	Andere Optionen, die beim Erstellen der Tabelle angegeben wurden.
Kommentar	Diese Spalte enthält einige zusätzliche Informationen. Bei MyISAM-Tabellen werden die Kommentare gespeichert, die beim Erstellen der Tabelle eingefügt wurden. Bei InnoDB-Tabellen werden die verbleibenden Speicherplatzinformationen des InnoDB-Tabellenbereichs gespeichert. Wenn es sich um eine Ansicht handelt, enthält diese Spalte das Textwort „VIEW“.

1.6 MySQL-Zeitleiste

1.7 MySQL-Entwicklungsmodell

Referenz: „Hochleistungs-MySQL“

Das obige ist der detaillierte Inhalt vonMySQL-Architektur. Für weitere Informationen folgen Sie bitte anderen verwandten Artikeln auf der PHP chinesischen Website!