Wissenspunkte zum Prinzip der MySQL-Parallelitätskontrolle

Mysql ist eine gängige relationale Open-Source-Datenbank, die leistungsstarke Datenspeicherdienste bereitstellt. Bei der Backend-Entwicklung kann es manchmal zu Leistungsengpässen kommen. Diese Engpässe kommen manchmal nicht von der Anwendung selbst, sondern von der Datenbankebene.

Daher hilft uns die Beherrschung einiger der zugrunde liegenden Prinzipien von MySQL dabei, MySQL besser zu verstehen und seine Leistung zu optimieren.

Dadurch werden leistungsstarke Backend-Dienste entwickelt.

1. MySQL-logisches Framework

Das Diagramm des MySQL-Logik-Frameworks sieht wie folgt aus:

Die oberste Schicht verarbeitet Verbindungen vom Client.

Hauptsächlich verantwortlich für Verbindungsverarbeitung, Autorisierungsauthentifizierung, Sicherheit usw. Mysql verwaltet auf dieser Ebene einen Thread-Pool, um Verbindungen von Clients zu verarbeiten. Mysql kann Benutzernamen- und Kennwortauthentifizierung verwenden,

SSL kann auch basierend auf der X.509-Zertifikatsauthentifizierung verwendet werden.

Die zweite Schicht besteht aus drei Teilen: Abfrage-Cache, Parser und Optimierer. Der Parser wird zum Analysieren von SQL-Anweisungen verwendet und der Optimierer optimiert die analysierten Anweisungen.

Vor dem Parsen der Abfrage überprüft der Server zunächst den Abfragecache. Wenn das entsprechende Abfrageergebnis darin gefunden werden kann, ist keine Abfrageparsing, -optimierung usw. erforderlich und das Abfrageergebnis wird direkt zurückgegeben. Gespeicherte Prozeduren, Trigger, Ansichten usw. werden alle auf dieser Ebene implementiert.

Die dritte Schicht ist die Speicher-Engine, die für das Speichern von Daten in MySQL, das Extrahieren von Daten, das Starten einer Transaktion usw. verantwortlich ist. Die Speicher-Engine kommuniziert über APIs mit der oberen Schicht. Diese APIs schirmen die Unterschiede zwischen verschiedenen Speicher-Engines ab und machen diese Unterschiede für den Abfrageprozess der oberen Schicht transparent. Die Speicher-Engine analysiert kein SQL. Die am häufigsten verwendete Speicher-Engine für MySQL ist InnoDB.

2. Parallelitätskontrolle von MySQL

Wenn mehrere Threads gleichzeitig Daten verarbeiten, kann dies zu Problemen bei der Parallelitätskontrolle führen.

2-1. Lese-/Schreibsperre

Wenn mehrere Threads nur Daten lesen, können sie tatsächlich gemeinsam lesen, ohne sich gegenseitig zu beeinträchtigen. Zu diesem Zeitpunkt sollte eine „Lesesperre“, auch als gemeinsame Sperre bezeichnet, verwendet werden.

Threads, die Lesesperren erwerben, blockieren sich nicht gegenseitig und können gleichzeitig eine Ressource lesen.

Wenn ein Thread Daten schreiben muss, sollte eine „Schreibsperre“, auch als exklusive Sperre bezeichnet, verwendet werden.

Eine Schreibsperre blockiert andere Schreibsperren und Lesesperren, bis der Schreibvorgang abgeschlossen ist.

2-2. Sperrgranularität

Lassen Sie uns zunächst ein Konzept klären: Je weniger Daten für eine bestimmte Ressource gesperrt werden müssen, desto höher ist die Parallelität, die das System verarbeiten kann.

Allerdings verbraucht das Sperren auch Ressourcen. Wenn das System viel Zeit mit der Verwaltung von Sperren verbringt, anstatt auf Daten zuzugreifen,

Dann kann die Systemleistung beeinträchtigt werden.

Eine gute „Sperrstrategie“ besteht daher darin, ein Gleichgewicht zwischen dem Sperraufwand und der Sicherheit der Daten zu finden. MySQL unterstützt mehrere Speicher-Engine-Architekturen.

Jede Speicher-Engine kann ihre eigene Sperrstrategie und Sperrgranularität implementieren.

2-3. Tabellensperren und Zeilensperren

Wie der Name schon sagt, sperrt eine Tabellensperre die gesamte Tabelle. Der Overhead der Tabellensperre ist relativ gering. Nach dem Hinzufügen einer Schreibsperre zu einer Tabelle werden alle Lese- und Schreibvorgänge anderer Benutzer auf dieser Tabelle blockiert.

Obwohl die Speicher-Engine in MySQL ihre eigenen Sperren bereitstellen kann, verwendet MySQL manchmal Tabellensperren, wie z. B. ALTER TABLE-Anweisungen.

Schreibsperren haben eine höhere Priorität als Lesesperren, deshalb kann eine Schreibsperrenanforderung am Anfang der Lesesperrenwarteschlange eingefügt werden.

Sperren auf Zeilenebene sperren die gesamte Zeile, wodurch die gleichzeitige Verarbeitung weitgehend unterstützt wird. Allerdings ist auch der Aufwand für das Entsperren und Hinzufügen von Sperren relativ groß. Zeilensperren werden nur auf der Ebene der Speicher-Engine implementiert.

Alle Speicher-Engines implementieren die Zeilensperre auf ihre eigene Weise.

3. MVCC

MVCC steht für „Multi-Version Concurrency Control“. Es kann als eine Variante von Zeilensperren betrachtet werden, vermeidet jedoch in vielen Fällen Sperrvorgänge.

Daher ist der Aufwand geringer.

Alle gängigen relationalen Datenbanken implementieren MVCC, aber die Implementierungsmechanismen sind unterschiedlich. Tatsächlich gibt es keinen einheitlichen Standard für MVCC.

Die meisten von ihnen implementieren jedoch nicht blockierende Lesevorgänge, und Schreibvorgänge sperren nur die erforderlichen Zeilen.

MVCC stellt sicher, dass die während der Ausführung in jeder Transaktion angezeigten Daten konsistent sind.

Da jedoch verschiedene Transaktionen zu unterschiedlichen Zeiten beginnen, können die für dieselbe Tabelle zum selben Zeitpunkt angezeigten Daten unterschiedlich sein.

In der InnoDB-Engine von MySQL wird dies erreicht, indem nach jeder Datensatzzeile zwei versteckte Spalten gespeichert werden.

Einer enthält den Zeitpunkt der Zeilenerstellung und der andere den Ablaufzeitpunkt (oder Löschzeitpunkt) der Zeile.

Was tatsächlich gespeichert wird, ist kein echter Zeitstempel, sondern eine „Systemversionsnummer“.

Bei jedem Öffnen einer Transaktion wird die Systemversionsnummer erhöht. Wenn eine Transaktion gestartet wird, wird die Systemversionsnummer als Transaktionsversionsnummer verwendet und mit der Versionsnummer der abgefragten Zeile verglichen.

Im Folgenden wird beschrieben, wie die Versionsnummer in gängigen CRUD-Operationen funktioniert:

EINFÜGEN

Aktuelle Systemversion als Zeilenversionsnummer speichern

LÖSCHEN

Speichert die aktuelle Systemversionsnummer in der „Löschversion“ dieser Datenzeile.

AKTUALISIEREN

Fügen Sie eine neue Zeile ein, speichern Sie die aktuelle Systemversionsnummer als Flugversionsnummer und speichern Sie die aktuelle Systemversionsnummer in der „gelöschten Version“ der ursprünglichen Zeile.

WÄHLEN

Suchen Sie nur nach Zeilen mit Versionen, die älter sind als die Version der aktuellen Transaktion. Dadurch wird sichergestellt, dass die von der Transaktion gelesenen Zeilen entweder bereits vorhanden sind oder

Es wird entweder eingefügt oder durch die Transaktion selbst geändert.

Die „Löschversion“ einer Zeile ist entweder nicht definiert oder größer als die aktuelle Transaktionsversionsnummer. Dadurch wird sichergestellt, dass die von der Transaktion gelesenen Zeilen

Wurde vor der Transaktion nicht gelöscht.

MVCC funktioniert nur auf den Isolationsebenen REPEATABLE READ und READ COMMITTED und nicht auf den anderen beiden Isolationsebenen.

Denn READ UNCOMMITTED liest immer die neusten Daten und nicht die Datenzeile, die der aktuellen Transaktionsversion entspricht. SERIALIZABLE sperrt alle gelesenen Zeilen.

Das Obige ist der detaillierte Inhalt des Parallelitätskontrollprinzips von MySQL. Wenn Sie Ergänzungen haben, wenden Sie sich bitte an den Herausgeber von 123WORDPRESS.COM.