Heim  >  Artikel  >  Datenbank  >  Was bedeutet MySQL-Sperre?

Was bedeutet MySQL-Sperre?

王林
王林Original
2020-06-28 11:39:373605Durchsuche

Der MySQL-Sperrmechanismus ist eine von der Datenbank entwickelte Regel, um die Konsistenz von Daten sicherzustellen und verschiedene gemeinsam genutzte Ressourcen bei gleichzeitigem Zugriff in Ordnung zu bringen. Jede MySQL-Speicher-Engine verwendet drei Arten von Sperrmechanismen: Sperren auf Tabellenebene, Sperren auf Zeilenebene und Sperren auf Seitenebene.

Was bedeutet MySQL-Sperre?

Detaillierte Erklärung der Sperre

(empfohlenes Tutorial: MySQL-Tutorial)

Der Datenbanksperrmechanismus ist einfach eine von der Datenbank entworfene Regel, um die Konsistenz der Daten sicherzustellen und verschiedene gemeinsam genutzte Ressourcen bei gleichzeitigem Zugriff in Ordnung zu bringen.

Jede Art von Datenbank erfordert einen entsprechenden Sperrmechanismus, daher bildet MySQL keine Ausnahme. Aufgrund der Merkmale ihrer eigenen Architektur verfügt die MySQL-Datenbank über mehrere Datenspeicher-Engines. Um den Anforderungen ihrer spezifischen Anwendungsszenarien gerecht zu werden, ist der Sperrmechanismus jeder Speicher-Engine darauf ausgelegt Die Designs sind für die spezifischen Szenarien optimiert, denen sie ausgesetzt sind, daher sind auch die Sperrmechanismen der einzelnen Speicher-Engines recht unterschiedlich.

MySQL-Speicher-Engines verwenden drei Arten (Ebenen) von Sperrmechanismen: Sperren auf Tabellenebene, Sperren auf Zeilenebene und Sperren auf Seitenebene.

Detaillierte Einführung:

1. Sperren auf Tabellenebene (Tabellenebene)

Sperren auf Tabellenebene ist die größte Granularität unter den MySQL-Speicher-Engines Verriegelungsmechanismus. Das größte Merkmal dieses Sperrmechanismus besteht darin, dass die Implementierungslogik sehr einfach ist und nur minimale negative Auswirkungen auf das System hat. Das Erlangen und Freigeben von Sperren geht also sehr schnell. Da Sperren auf Tabellenebene die gesamte Tabelle auf einmal sperren, kann das Deadlock-Problem, das uns plagt, vermieden werden.

Die größte negative Auswirkung einer großen Sperrgranularität besteht natürlich darin, dass die Wahrscheinlichkeit eines Konflikts um Sperrressourcen am höchsten ist, was die Effizienz erheblich verringert.

Sperren auf Tabellenebene wird hauptsächlich von nicht-transaktionalen Speicher-Engines wie MyISAM, MEMORY und CSV verwendet.

2. Sperren auf Zeilenebene (Zeilenebene)

Das größte Merkmal der Sperrung auf Zeilenebene ist, dass die Granularität des gesperrten Objekts sehr gering ist, was auch die erreichte Sperrgranularität ist von der derzeit größten Datenbankverwaltungssoftware. Da die Sperrgranularität sehr gering ist, ist auch die Wahrscheinlichkeit eines Konflikts um Sperrressourcen minimal, was der Anwendung größtmögliche Möglichkeiten zur gleichzeitigen Verarbeitung bieten und die Gesamtleistung einiger Anwendungssysteme verbessern kann, die eine hohe Parallelität erfordern.

Obwohl es große Vorteile bei der gleichzeitigen Verarbeitung bietet, bringt das Sperren auf Zeilenebene auch viele Nachteile mit sich. Da die Granularität der Sperrressourcen sehr gering ist, müssen jedes Mal mehr Dinge getan werden, um die Sperre zu erhalten und freizugeben, und der Verbrauch ist natürlich höher. Darüber hinaus ist das Sperren auf Zeilenebene auch am anfälligsten für Deadlocks.

Die Hauptanwendung der Sperrung auf Zeilenebene ist die InnoDB-Speicher-Engine.

3. Sperren auf Seitenebene (Seitenebene)

Sperren auf Seitenebene ist eine einzigartige Sperrebene in MySQL und kommt in anderer Datenbankverwaltungssoftware nicht allzu häufig vor.

Das Merkmal der Sperrung auf Seitenebene besteht darin, dass die Sperrgranularität zwischen der Sperrung auf Zeilenebene und der Sperrung auf Tabellenebene liegt, sodass der zum Erhalten der Sperre erforderliche Ressourcenaufwand und die gleichzeitige Verarbeitungsfähigkeit, die sie bereitstellen kann, ebenfalls dazwischen liegen das obige zwischen den beiden. Darüber hinaus führen Sperren auf Seitenebene und Sperren auf Zeilenebene zu einem Deadlock.

Im Prozess der Ressourcensperrung in der Datenbank wird mit abnehmender Granularität der gesperrten Ressourcen immer mehr Speicher verbraucht, um die gleiche Datenmenge zu sperren, und auch der Implementierungsalgorithmus wird immer komplexer . Je komplexer es ist. Da jedoch die Granularität gesperrter Ressourcen abnimmt, nimmt auch die Wahrscheinlichkeit ab, dass Anwendungszugriffsanforderungen auf Sperrwartezeiten stoßen, und die allgemeine Parallelität des Systems nimmt ebenfalls zu.

Die Hauptanwendung des Sperrens auf Seitenebene ist die BerkeleyDB-Speicher-Engine.

Zusammenfassung:

Die Eigenschaften dieser drei Sperren in MySQL lassen sich grob wie folgt zusammenfassen:

Sperre auf Tabellenebene: geringer Overhead, schnell Sperren; es treten keine Deadlocks auf; die Wahrscheinlichkeit von Sperrenkonflikten ist am niedrigsten.

Sperren auf Zeilenebene: Es treten hohe Sperren auf; ist am kleinsten, Sperrkonflikte treten am geringsten auf und die Parallelität ist am höchsten Tabellensperren und Zeilensperren, Parallelität Durchschnittlicher Grad.

Anwendbar: Aus Sicht der Sperren eignen sich Sperren auf Tabellenebene besser für abfragebasierte Anwendungen, bei denen nur eine kleine Datenmenge gemäß Indexbedingungen aktualisiert wird, z. B. Sperren auf Zeilenebene Geeignet für Anwendungen mit einer großen Anzahl von Anwendungen. Aktualisieren Sie gleichzeitig eine kleine Menge unterschiedlicher Daten entsprechend den Indexbedingungen und verfügen Sie gleichzeitig über gleichzeitige Abfrageanwendungen, z. B. einige OLTP-Systeme (Online Transaction Processing).

Das obige ist der detaillierte Inhalt vonWas bedeutet MySQL-Sperre?. Für weitere Informationen folgen Sie bitte anderen verwandten Artikeln auf der PHP chinesischen Website!

Stellungnahme:
Der Inhalt dieses Artikels wird freiwillig von Internetnutzern beigesteuert und das Urheberrecht liegt beim ursprünglichen Autor. Diese Website übernimmt keine entsprechende rechtliche Verantwortung. Wenn Sie Inhalte finden, bei denen der Verdacht eines Plagiats oder einer Rechtsverletzung besteht, wenden Sie sich bitte an admin@php.cn