【MySQL】Parallelitätskontrolle

Immer wenn mehrere Abfragen gleichzeitig Daten ändern müssen, treten Probleme bei der Parallelitätskontrolle auf. Hier besprechen wir die Parallelitätskontrolle von MySQL auf zwei Ebenen: der Serverschicht und der Speicher-Engine-Schicht. Parallelitätskontrolle ist ein großes Thema, und es gibt eine große Menge theoretischer Literatur, die es ausführlich behandelt. Hier diskutieren wir nur kurz, wie MySQL das gleichzeitige Lesen und Schreiben steuert.

Nehmen Sie als Beispiel die E-Mail-Box des Unix-Systems. Das typische Mbox-Dateiformat ist sehr einfach. Alle E-Mails in einem Mbox-Postfach werden zusammen serialisiert und Ende an Ende verbunden. Dieses Format eignet sich sehr gut zum Lesen von Feixi-E-Mail-Informationen und es ist auch einfach, E-Mails zuzustellen. Hängen Sie einfach neuen E-Mail-Inhalt an das Ende der Datei.

Aber was passiert, wenn zwei Prozesse gleichzeitig E-Mails an dasselbe Postfach zustellen? Offensichtlich werden die Daten im Postfach zerstört und der Inhalt der beiden E-Mails an das Ende der Postfachdatei angehängt. Ein gut konzipiertes Postfachzustellungssystem verwendet Sperren, um Datenbeschädigungen zu verhindern. Wenn ein Client versucht, E-Mails zuzustellen, und das Postfach von einem anderen Client gesperrt wird, muss er warten, bis die Sperre aufgehoben wird, bevor die Zustellung erfolgen kann.

Obwohl dieses Sperrschema in tatsächlichen Anwendungsumgebungen gut funktioniert, unterstützt es keine gleichzeitige Verarbeitung. Da immer nur ein Prozess die Postfachdaten ändern kann, stellt dies bei Postfachsystemen mit großer Kapazität ein Problem dar.

Lese-/Schreibsperre

Es gibt keine derartigen Probleme beim Lesen von Daten aus dem Postfach, selbst wenn mehrere Benutzer gleichzeitig lesen, gibt es kein Problem. Da durch das Lesen die Daten nicht verändert werden, liegt kein Fehler vor. Aber was passiert, wenn ein Kunde das Postfach liest, während ein anderer Benutzer versucht, die E-Mail-Nummer 25 zu löschen? Die Schlussfolgerung ist ungewiss. Der lesende Client wird möglicherweise mit einem Fehler beendet oder kann keine konsistenten Postfachdaten lesen. Aus Sicherheitsgründen erfordert daher bereits das Auslesen des Postfachs besondere Aufmerksamkeit.

Wenn Sie das obige Postfach als Tabelle in der Datenbank und die E-Mail als Zeile in der Tabelle behandeln, ist es leicht zu erkennen, dass das gleiche Problem immer noch besteht. In vielerlei Hinsicht ist ein Postfach eine einfache Datenbanktabelle. Das Ändern von Datensätzen in einer Datenbanktabelle ähnelt dem Löschen oder Ändern von E-Mail-Informationen in einem Postfach.

Die Lösung für dieses klassische Problem ist die Parallelitätskontrolle (Lesesperren und Schreibsperren). Tatsächlich ist es sehr einfach, das Problem beim gleichzeitigen Lesen oder Schreiben zu lösen, indem ein Sperrsystem implementiert wird, das aus zwei Arten von Sperren besteht. Diese beiden Arten von Sperren werden normalerweise gemeinsame Sperre und exklusive Sperre genannt, auch Lesesperre und Schreibsperre genannt.

Lassen Sie uns hier nicht diskutieren, wie es implementiert wird. Beschreiben wir das Konzept der Sperre wie folgt: Lesesperren werden gemeinsam genutzt oder sie blockieren sich nicht gegenseitig. Mehrere Clients können gleichzeitig dieselbe Ressource lesen, ohne sich gegenseitig zu stören. Schreibsperren sind exklusiv, was bedeutet, dass eine Schreibsperre andere Schreibsperren und Lesesperren blockiert. Nur so kann sichergestellt werden, dass jeweils nur ein Benutzer Schreibvorgänge ausführen kann Verhindern Sie, dass andere Benutzer dieselbe Ressource lesen, auf die geschrieben wird.

In einem tatsächlichen Datenbanksystem erfolgt die Sperrung jeden Moment. Wenn ein Benutzer einen bestimmten Teil der Daten ändert, verhindert MySQL durch Sperren, dass andere Benutzer dieselben Daten lesen. Meistens ist die interne Verwaltung von MySQL-Sperren transparent.

Sperrgranularität

Eine Möglichkeit, Parallelität auf gemeinsam genutzten Ressourcen bereitzustellen, besteht darin, das Sperren von Objekten selektiver zu gestalten. Versuchen Sie, nur einen Teil der Daten zu sperren, die geändert werden müssen, und nicht alle Ressourcen. Ein idealerer Ansatz besteht darin, genau nur die Datenteile zu sperren, die geändert werden (insbesondere die geänderten Felder). Zu jedem Zeitpunkt gilt für eine bestimmte Ressource: Je kleiner die Menge der gesperrten Daten ist, desto höher ist die Parallelität des Systems, solange kein Konflikt miteinander besteht.

Das Problem ist, dass das Sperren auch Ressourcen verbraucht. Verschiedene Sperrvorgänge, einschließlich der Erfassung der Sperre, der Überprüfung, ob die Sperre freigegeben wurde, der Freigabe der Sperre usw., erhöhen den Systemaufwand. Wenn das System viel Zeit mit der Verwaltung von Sperren verbringt, anstatt auf Daten zuzugreifen, kann die Systemleistung beeinträchtigt werden.

Die sogenannte Sperrstrategie besteht darin, ein Gleichgewicht zwischen Sperraufwand und Datensicherheit anzustreben. Dieses Gleichgewicht wirkt sich natürlich nicht auf die Leistung aus. Die meisten kommerziellen Datenbanksysteme bieten im Allgemeinen keine Sperren auf Zeilenebene die Tabelle und implementiert sie auf verschiedene komplexe Arten, um bei vielen Sperren eine möglichst bessere Leistung zu erzielen.

MySQL bietet eine Vielzahl von Optionen, und jede MySQL-Speicher-Engine kann ihre eigene Sperrstrategie und Sperrgranularität implementieren. Die Sperrverwaltung ist eine sehr wichtige Entscheidung beim Entwurf einer Speicher-Engine. Durch Festlegen der Sperrgranularität auf einem bestimmten Niveau kann für bestimmte Anwendungsszenarien eine bessere Leistung erzielt werden. Aber für andere Anwendungsszenarien werden die Kollegen gute Unterstützung verlieren. Glücklicherweise unterstützt MySQL mehrere Speicher-Engine-Architekturen, sodass keine einzige universelle Lösung erforderlich ist. Im Folgenden werden die beiden wichtigsten Sperrstrategien vorgestellt.

Tabellensperre (Tabellensperre)

Tabellensperre ist die grundlegendste Sperrstrategie in MySQL und die Strategie mit dem geringsten Overhead . Die Tabellensperre ist dem zuvor beschriebenen Mailbox-Sperrmechanismus sehr ähnlich: Sie sperrt die gesamte Tabelle. Bevor ein Benutzer Schreibvorgänge (Einfügen, Löschen, Aktualisieren usw.) für die Tabelle ausführen kann, muss er eine Schreibsperre erhalten. Dadurch werden alle Lese- und Schreibvorgänge für die Tabelle durch andere Benutzer blockiert. Nur wenn keine Schreibsperre vorhanden ist, können andere lesende Benutzer die Lesesperre erhalten und Lesesperren blockieren sich nicht gegenseitig.

Tischsperren können in bestimmten Szenarien auch eine gute Leistung erbringen. Lesesperren für lokale Tabellen unterstützen beispielsweise 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 (nicht einfügbare Sperre) vor der Schreibsperre).

Obwohl die Speicher-Engine ihre eigenen Sperren verwalten kann, Mysql selbst verwendet eine Vielzahl effektiver Tabellensperren, um unterschiedliche Zwecke zu erreichen. Beispielsweise verwendet der Server Tabellensperren für Anweisungen wie alter table und ignoriert dabei den Sperrmechanismus der Speicher-Engine.

[Hinweis: Der Sperrmechanismus wird von der Speicher-Engine verwaltet, aber MySQL selbst verwaltet diesen Sperrmechanismus manchmal zwangsweise]

Zeilensperre (Zeilensperre)

Sperren auf Zeilenebene können die gleichzeitige Verarbeitung weitestgehend unterstützen (aber bringen auch den größten Sperraufwand mit sich) . Es ist bekannt, dass Sperren auf Zeilenebene in InnoDB und XtraDB sowie einigen anderen Speicher-Engines implementiert sind. Sperren auf Zeilenebene werden nur auf der Speicher-Engine-Ebene implementiert, und die MySQL-Serverebene (siehe ggf. das logische Architekturdiagramm im vorherigen Artikel) ist nicht implementiert. Die Serverschicht hat keine Kenntnis von der Sperrimplementierung in der Speicher-Engine. Während wir in diesem Kapitel und im gesamten Buch fortfahren, weisen alle Speicher-Engines auf ihre eigene Art und Weise Sperrmechanismen auf .

Immer wenn mehrere Abfragen gleichzeitig Daten ändern müssen, treten Probleme bei der Parallelitätskontrolle auf. Hier besprechen wir die Parallelitätskontrolle von MySQL auf zwei Ebenen: der Serverschicht und der Speicher-Engine-Schicht. Parallelitätskontrolle ist ein großes Thema, und es gibt eine große Menge theoretischer Literatur, die es ausführlich behandelt. Hier diskutieren wir nur kurz, wie MySQL das gleichzeitige Lesen und Schreiben steuert.

Nehmen Sie als Beispiel die E-Mail-Box des Unix-Systems. Das typische Mbox-Dateiformat ist sehr einfach. Alle E-Mails in einem Mbox-Postfach werden zusammen serialisiert und Ende an Ende verbunden. Dieses Format eignet sich sehr gut zum Lesen von Feixi-E-Mail-Informationen und es ist auch einfach, E-Mails zuzustellen. Hängen Sie einfach neuen E-Mail-Inhalt an das Ende der Datei.

Aber was passiert, wenn zwei Prozesse gleichzeitig E-Mails an dasselbe Postfach zustellen? Offensichtlich werden die Daten im Postfach zerstört und der Inhalt der beiden E-Mails an das Ende der Postfachdatei angehängt. Ein gut konzipiertes Postfachzustellungssystem verwendet Sperren, um Datenbeschädigungen zu verhindern. Wenn ein Kunde versucht, Post zuzustellen und das Postfach von einem anderen Kunden gesperrt wird, muss er warten, bis die Sperre aufgehoben wird, bevor die Zustellung erfolgen kann.

Obwohl dieses Sperrschema in tatsächlichen Anwendungsumgebungen gut funktioniert, unterstützt es keine gleichzeitige Verarbeitung. Da immer nur ein Prozess die Postfachdaten ändern kann, stellt dies bei Postfachsystemen mit großer Kapazität ein Problem dar.

Lese-/Schreibsperre

Es gibt keine derartigen Probleme beim Lesen von Daten aus dem Postfach, selbst wenn mehrere Benutzer gleichzeitig lesen, gibt es kein Problem. Da durch das Lesen die Daten nicht verändert werden, liegt kein Fehler vor. Aber was passiert, wenn ein Kunde das Postfach liest, während ein anderer Benutzer versucht, die E-Mail-Nummer 25 zu löschen? Die Schlussfolgerung ist ungewiss. Der lesende Client wird möglicherweise mit einem Fehler beendet oder kann keine konsistenten Postfachdaten lesen. Aus Sicherheitsgründen erfordert daher bereits das Auslesen des Postfachs besondere Aufmerksamkeit.

Wenn Sie das obige Postfach als Tabelle in der Datenbank und die E-Mail als Zeile in der Tabelle behandeln, ist es leicht zu erkennen, dass das gleiche Problem immer noch besteht. In vielerlei Hinsicht ist ein Postfach eine einfache Datenbanktabelle. Das Ändern von Datensätzen in einer Datenbanktabelle ähnelt dem Löschen oder Ändern von E-Mail-Informationen in einem Postfach.

Die Lösung für diese Art von klassischem Problem ist die Parallelitätskontrolle (Lesesperren und Schreibsperren). Tatsächlich ist es sehr einfach, das Problem beim gleichzeitigen Lesen oder Schreiben zu lösen, indem ein Sperrsystem implementiert wird, das aus zwei Arten von Sperren besteht. Diese beiden Arten von Sperren werden normalerweise gemeinsame Sperre und exklusive Sperre genannt, auch Lesesperre und Schreibsperre genannt.

Lassen Sie uns hier nicht diskutieren, wie es implementiert wird. Beschreiben wir das Konzept der Sperre wie folgt: Lesesperren werden gemeinsam genutzt oder sie blockieren sich nicht gegenseitig. Mehrere Clients können gleichzeitig dieselbe Ressource lesen, ohne sich gegenseitig zu stören. Schreibsperren sind exklusiv, was bedeutet, dass eine Schreibsperre andere Schreibsperren und Lesesperren blockiert. Nur so kann sichergestellt werden, dass jeweils nur ein Benutzer Schreibvorgänge ausführen kann Verhindern Sie, dass andere Benutzer dieselbe Ressource lesen, auf die geschrieben wird.

In einem tatsächlichen Datenbanksystem erfolgt die Sperrung jeden Moment. Wenn ein Benutzer einen bestimmten Teil der Daten ändert, verhindert MySQL durch Sperren, dass andere Benutzer dieselben Daten lesen. Meistens ist die interne Verwaltung von MySQL-Sperren transparent.

Sperrgranularität

Eine Möglichkeit, Parallelität auf gemeinsam genutzten Ressourcen bereitzustellen, besteht darin, das Sperren von Objekten selektiver zu gestalten. Versuchen Sie, nur einen Teil der Daten zu sperren, die geändert werden müssen, und nicht alle Ressourcen. Ein idealerer Ansatz besteht darin, genau nur die Datenteile zu sperren, die geändert werden (insbesondere die geänderten Felder). Zu jedem Zeitpunkt gilt für eine bestimmte Ressource: Je kleiner die Menge der gesperrten Daten ist, desto höher ist die Parallelität des Systems, solange kein Konflikt miteinander besteht.

Das Problem ist, dass das Sperren auch Ressourcen verbraucht. Verschiedene Sperrvorgänge, einschließlich der Erfassung der Sperre, der Überprüfung, ob die Sperre freigegeben wurde, der Freigabe der Sperre usw., erhöhen den Systemaufwand. Wenn das System viel Zeit mit der Verwaltung von Sperren verbringt, anstatt auf Daten zuzugreifen, kann die Systemleistung beeinträchtigt werden.

Die sogenannte Sperrstrategie besteht darin, ein Gleichgewicht zwischen Sperraufwand und Datensicherheit anzustreben. Dieses Gleichgewicht wirkt sich natürlich nicht auf die Leistung aus. Die meisten kommerziellen Datenbanksysteme bieten im Allgemeinen keine Sperren auf Zeilenebene die Tabelle und implementiert sie auf verschiedene komplexe Arten, um bei vielen Sperren eine möglichst bessere Leistung zu erzielen.

MySQL bietet eine Vielzahl von Optionen, und jede MySQL-Speicher-Engine kann ihre eigene Sperrstrategie und Sperrgranularität implementieren. Die Sperrverwaltung ist eine sehr wichtige Entscheidung beim Entwurf einer Speicher-Engine. Durch Festlegen der Sperrgranularität auf einem bestimmten Niveau kann für bestimmte Anwendungsszenarien eine bessere Leistung erzielt werden. Aber für andere Anwendungsszenarien werden die Kollegen gute Unterstützung verlieren. Glücklicherweise unterstützt MySQL mehrere Speicher-Engine-Architekturen, sodass keine einzige universelle Lösung erforderlich ist. Im Folgenden werden die beiden wichtigsten Sperrstrategien vorgestellt.

Tabellensperre

Tabellensperre ist die grundlegendste Sperrstrategie in MySQL und die Strategie mit dem geringsten Overhead . Die Tabellensperre ist dem zuvor beschriebenen Mailbox-Sperrmechanismus sehr ähnlich: Sie sperrt die gesamte Tabelle. Bevor ein Benutzer Schreibvorgänge (Einfügen, Löschen, Aktualisieren usw.) für die Tabelle ausführen kann, muss er eine Schreibsperre erhalten. Dadurch werden alle Lese- und Schreibvorgänge für die Tabelle durch andere Benutzer blockiert. Nur wenn keine Schreibsperre vorhanden ist, können andere lesende Benutzer die Lesesperre erhalten und Lesesperren blockieren sich nicht gegenseitig.

Tischsperren können in bestimmten Szenarien auch eine gute Leistung erbringen. Lesesperren für lokale Tabellen unterstützen beispielsweise 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 (nicht einfügbare Sperre) vor der Schreibsperre).

Obwohl die Speicher-Engine ihre eigenen Sperren verwalten kann, Mysql selbst verwendet eine Vielzahl effektiver Tabellensperren, um unterschiedliche Zwecke zu erreichen. Beispielsweise verwendet der Server Tabellensperren für Anweisungen wie alter table und ignoriert dabei den Sperrmechanismus der Speicher-Engine.

[Hinweis: Der Sperrmechanismus wird von der Speicher-Engine verwaltet, aber MySQL selbst verwaltet diesen Sperrmechanismus manchmal zwangsweise]

Zeilensperre (Zeilensperre)

Sperren auf Zeilenebene können die gleichzeitige Verarbeitung weitestgehend unterstützen (aber bringen auch den größten Sperraufwand mit sich) . Es ist bekannt, dass Sperren auf Zeilenebene in InnoDB und XtraDB sowie einigen anderen Speicher-Engines implementiert sind. Sperren auf Zeilenebene werden nur auf der Speicher-Engine-Ebene implementiert, und die MySQL-Serverebene (siehe ggf. das logische Architekturdiagramm im vorherigen Artikel) ist nicht implementiert. Die Serverschicht hat keine Kenntnis von der Sperrimplementierung in der Speicher-Engine. Während wir in diesem Kapitel und im gesamten Buch fortfahren, weisen alle Speicher-Engines auf ihre eigene Art und Weise Sperrmechanismen auf .

Das Obige ist der Inhalt der [MySQL]-Parallelitätskontrolle. Weitere verwandte Inhalte finden Sie auf der chinesischen PHP-Website (www.php.cn).