MariaDB
 sql >> Datenbank >  >> RDS >> MariaDB

Verständnis der Lock-Granularität in MySQL

Wenn Sie schon seit einiger Zeit mit MySQL arbeiten, haben Sie wahrscheinlich die Begriffe „Sperren auf Tabellenebene“ und „Sperren auf Zeilenebene“ gehört. Diese Begriffe beziehen sich auf die Lock-Granularität in MySQL - in diesem Blog erklären wir, was sie bedeuten und wofür sie verwendet werden können.

Was ist Sperrgranularität in MySQL?

Jede MySQL-Speicher-Engine unterstützt unterschiedliche Granularitätsstufen für ihre Sperren. MySQL hat drei Sperrebenen:Sperren auf Zeilenebene, Sperren auf Seitenebene und Sperren auf Tabellenebene. Jede MySQL-Speicher-Engine implementiert das Sperren anders, wodurch Sie einige deutliche Vor- und Nachteile haben. Wir sehen uns zuerst an, was Lock-Granularity ist, und schauen uns dann an, wie alles in verschiedenen Speicher-Engines funktioniert.

Im Großen und Ganzen fallen Sperren in MySQL in eine dieser Kategorien. Sperren können sein:

  • Seitenebene - solche Arten von Lock-Granularitäten waren in älteren MySQL-Engines verfügbar, insbesondere in BDB jetzt veraltet ab MySQL 5.1. Kurz gesagt, BDB war eine Speicher-Engine, die in den älteren Versionen von MySQL enthalten war, und es war eine transaktionale Speicher-Engine, die Sperren auf Seitenebene durchführte. Da diese Arten von Sperrgranularitäten nicht mehr verwendet werden, gehen wir hier nicht näher darauf ein, aber im Allgemeinen sind diese Sperren auf die Daten und Indizes beschränkt, die sich auf einer bestimmten Seite befinden. Wenn Sie mehr über BDB erfahren möchten, sollten Sie auf der Seite zu MariaDB weitere Informationen finden.

  • Tabellenebene – MySQL verwendet Sperren auf Tabellenebene für alle Speicher-Engines außer InnoDB.

  • Zeilenebene – Sperren auf Zeilenebene wird von InnoDB verwendet.

Die Vor- und Nachteile des Sperrens auf Tabellenebene

MySQL verwendet Sperren auf Tabellenebene für alle Speicher-Engines außer InnoDB, was bedeutet, dass Sperren auf Tabellenebene für Tabellen verwendet wird, auf denen die Speicher-Engines MyISAM, MEMORY und MERGE ausgeführt werden, wodurch nur eine Sitzung gleichzeitig Tabellen aktualisieren kann . Sperren auf Tabellenebene haben einige deutliche Vorteile gegenüber Sperren auf Zeilenebene (z. B. erfordert das Sperren auf Tabellenebene im Allgemeinen etwas weniger Arbeitsspeicher als das Sperren auf Zeilenebene, da das Sperren auf Zeilenebene etwas Arbeitsspeicher pro Zeile (oder Gruppe) der Zeilen erfordert die gesperrt sind, und es ist normalerweise schnell, weil nur eine Sperre involviert ist. Tabellenschreibsperren werden auf eine Tabelle gesetzt, wenn keine Sperren darauf vorhanden sind - wenn es bereits vorhandene Sperren auf der betreffenden Tabelle gibt, werden die Tabellensperranforderungen gesetzt Es ist erwähnenswert, dass das Sperren auf Tabellenebene auch einige eindeutige Nachteile hat, die für sich selbst einzigartig sind – zum Beispiel ist es möglicherweise nicht sehr gut für Anwendungen geeignet, die viele Transaktionen erfordern, die „hin und her“ gehen (z. , eine Online-Banking-Anwendung), da immer nur eine Sitzung gleichzeitig in eine Tabelle schreiben kann und einige der Tabellen, die das Sperren auf Tabellenebene unterstützen (z. B. MyISAM), das ACID-Modell nicht unterstützen.

Hier ist ein Beispiel:Stellen Sie sich eine Bankanwendung vor, die zwei Tabellen in einer Datenbank verwendet – nehmen wir an, diese Tabellen heißen „Überprüfung“ und „Ersparnisse“. Sie müssen 100 $ vom Girokonto einer Person auf ihr Sparkonto überweisen. Logischerweise würden Sie die folgenden Schritte ausführen:

  1. Stellen Sie sicher, dass der Kontostand mehr als 100 $ beträgt.

  2. Ziehen Sie $100 vom Girokonto ab.

  3. Fügen Sie $100 auf das Sparkonto hinzu.

Um diese Aktionen auszuführen, benötigen Sie einige Abfragen, zum Beispiel:

SELECT balance FROM checking WHERE account_id = 123;
UPDATE checking SET balance = balance - 100 WHERE account_id = 123;
UPDATE savings SET balance = balance + 100 WHERE account_id = 123;

Diese Abfragen mögen einfach aussehen, aber wenn Sie MyISAM verwenden (wir verwenden MyISAM als Beispiel, da es eine der primären Speicher-Engines ist, die Sperren auf Tabellenebene unterstützt), sollten Sie damit vertraut sein Die Engine unterstützt ACID auch nicht, was bedeutet, dass Sie Pech haben, wenn der Datenbankserver während der Ausführung einer dieser Abfragen abstürzt:Die Leute könnten am Ende Bargeld auf beiden Konten oder auf keinem von beiden haben. Die einzige Engine, die ACID-basierte Transaktionen in MySQL unterstützt, ist InnoDB. Wenn Sie also viele zuverlässige Transaktionen benötigen, könnte es sich lohnen, sich damit zu beschäftigen. InnoDB unterstützt auch Sperren auf Zeilenebene – das werden wir uns jetzt ansehen.

Die Vor- und Nachteile des Sperrens auf Zeilenebene

MySQL verwendet Sperren auf Zeilenebene für InnoDB-Tabellen, um den gleichzeitigen Schreibzugriff durch mehrere Sitzungen zu unterstützen. Einige der Vorteile der Verwendung von Sperren auf Zeilenebene umfassen die Möglichkeit, eine einzelne Zeile für längere Zeit zu sperren, und weniger Sperrkonflikte, wenn viele Threads auf verschiedene Zeilen zugreifen. Das Sperren auf Zeilenebene hat jedoch auch Nachteile:Einer davon ist, dass das Sperren auf Zeilenebene normalerweise mehr Speicher beansprucht als das Sperren auf Seiten- oder Tabellenebene, es ist auch normalerweise langsamer als das Sperren auf Seiten- oder Tabellenebene, da die Engine muss mehr Sperren erwerben. InnoDB ist eine der Engines, die einen Sperrmechanismus auf Zeilenebene unterstützen:Es ist auch ACID-konform, was bedeutet, dass es gut für transaktionsbasierte Anwendungen geeignet ist (siehe obiges Beispiel). Jetzt schauen wir uns an, wie Lock-Granularity in einer der MySQL-Speicher-Engines funktioniert.

Wie funktioniert Sperrgranularität in InnoDB?

InnoDB ist weithin dafür bekannt, Sperren auf Zeilenebene zu unterstützen, aber es ist auch erwähnenswert, dass die Engine mehrere Arten von Sperren unterstützt, was bedeutet, dass Sie sowohl Sperren auf Zeilenebene als auch auf Tabellenebene verwenden können. InnoDB führt Sperren auf Zeilenebene durch, indem gemeinsame oder exklusive Sperren für die Indexdatensätze gesetzt werden, auf die es stößt, wenn es einen Tabellenindex durchsucht oder scannt. Eine gemeinsame Sperre ist eine solche Sperre, die es der Transaktion, die die Sperre hält, erlaubt, die betreffende Zeile zu lesen, eine exklusive Sperre hingegen erlaubt der Transaktion, die die Sperre hält, eine Zeile zu aktualisieren oder zu löschen.

InnoDB hat auch andere Arten von Sperren - einige von ihnen beinhalten gemeinsame und exklusive Sperren, Intention-Sperren, Datensatz-Sperren, Gap-Sperren, Next-Key-Sperren und Next-Intention-Sperren. Absichtssperren können zum Beispiel auch geteilt oder exklusiv sein – solche Sperren zeigen normalerweise an, dass eine Transaktion beabsichtigt, eine bestimmte Art von Sperre (eine geteilte Sperre oder eine exklusive Sperre) auf einzelne Zeilen in einer Tabelle zu setzen, eine Datensatzsperre ist eine Sperren eines Indexeintrags usw.

Im Allgemeinen unterscheidet sich die Granularität von InnoDB-Sperren von der Granularität von Sperren, die in anderen MySQL-Speicher-Engines (z. B. MyISAM) vorhanden ist, da bei Verwendung von Sperren auf Tabellenebene nur eine Sitzung zum Aktualisieren bestimmter Tabellen bei einer die zeit kann rennen. Wenn Sperren auf Zeilenebene verwendet wird, unterstützt MySQL den gleichzeitigen Schreibzugriff über mehrere Sitzungen hinweg, was Speicher-Engines mit Sperren auf Zeilenebene (InnoDB) zu einer geeigneten Wahl für unternehmenskritische Anwendungen macht.

Lock-Granularität und Deadlocks

Sperrgranularität und Sperrebenen in MySQL können eine großartige Sache sein, aber sie können auch Probleme verursachen. Eines der häufigsten Probleme, das durch Sperrgranularität verursacht wird, sind Deadlocks – ein Deadlock tritt auf, wenn verschiedene MySQL-Transaktionen nicht fortgesetzt werden können, weil jede von ihnen eine Sperre hält, die die andere benötigt. Glücklicherweise ist die Deadlock-Erkennung bei Verwendung der InnoDB-Speicher-Engine standardmäßig aktiviert – wenn ein Deadlock erkannt wird, setzt InnoDB automatisch eine Transaktion zurück. Wenn Sie beim Umgang mit Sperrgranularität in MySQL auf Deadlocks stoßen, machen Sie sich keine Sorgen – erwägen Sie einfach, Ihre Transaktion neu zu starten. Um Ihre Datenbank proaktiv zu überwachen, sollten Sie auch die Funktionen von ClusterControl nutzen.

Wie kann ClusterControl Ihnen helfen?

Hier sind einige der Dinge, bei denen ClusterControl, das von Multiplenines entwickelt wurde, Ihnen helfen kann:

  • Der Schutz all Ihrer Geschäftsdaten

    • Falls Ihre Daten beschädigt sind (dies kann dadurch verursacht werden, dass keine ACID-kompatible Speicher-Engine verwendet wird oder auch durch andere Faktoren wie oben beschrieben) kann das Tool einen automatischen Prozess ausführen, der tatsächlich überprüft, ob Sie Ihre Daten wiederherstellen können.

    • Das Tool kann Sie darüber informieren, welche Datenbanken nicht gesichert sind, oder Ihnen den Status Ihrer Sicherungen anzeigen (ob sie waren erfolgreich oder sie sind gescheitert)

  • Die Automatisierung Ihrer Datenbankoperationen

    • ClusterControl kann Ihnen helfen sicherzustellen, dass Ihre Systemadministratoren, Entwickler und DBAs ganze Datenbank-Cluster effizient und mit minimalem Risiko verwalten, indem Sie die Industrie verwenden Best Practices

  • Effiziente Verwaltung Ihrer Datenbankinfrastruktur im Allgemeinen

    • Der heutige Technologiewandel in Kombination mit ausgefeilten Infrastrukturlösungen erfordert fortschrittliche Tools und Kenntnisse, um eine hohe Verfügbarkeit und optimale Leistung zu erreichen Ihre geschäftskritischen Anwendungen. ClusterControl kann Ihnen auch bei der Bereitstellung, Überwachung, Verwaltung und Skalierung der beliebtesten Open-Source-Datenbanktechnologien helfen, darunter MySQL, MariaDB, MongoDB, PostgreSQL, TimeScaleDB und andere.

Um mehr darüber zu erfahren, wie ClusterControl Ihnen helfen kann, Ihre Geschäftsabläufe zu rationalisieren, behalten Sie den Datenbank-Blog von Multiplenines im Auge.

Zusammenfassung

Verschiedene MySQL-Speicher-Engines verfügen über unterschiedliche Arten von Sperrgranularitäten. Bevor Sie sich für die Speicher-Engine entscheiden, die Sie verwenden sollten, stellen Sie sicher, dass Sie so viele Informationen wie möglich über die betreffende Speicher-Engine haben (z. B. sollte, wie bereits erwähnt, MyISAM beim Umgang mit unternehmenskritischen Daten vermieden werden, da es nicht ACID-konform ist). alle damit verbundenen Auswirkungen auf die Leistung, einschließlich Sperrgranularität, Deadlocks und dem Rest, und wählen Sie mit Bedacht aus.