Tiefgreifendes Verständnis der verschiedenen Sperren von MySQL

In der Datenbank sind Daten neben der Konkurrenz um herkömmliche Computerressourcen (wie CPU, RAM, E/A usw.) auch eine Ressource, die von vielen Benutzern gemeinsam genutzt wird. Wenn die Konsistenz und Gültigkeit des gleichzeitigen Datenzugriffs gewährleistet werden soll, ist dies ein Problem, das alle Datenbanken lösen müssen. Sperrkonflikte sind auch ein wichtiger Faktor, der die gleichzeitige Zugriffsleistung der Datenbank beeinflusst. Aus dieser Perspektive sind Sperren für Datenbanken besonders wichtig und komplexer.

Tabellensperren:
	Während der Operation ist die gesamte Tabellenzeilensperre gesperrt:
	Während der Bedienung wird die aktuelle Bedienzeile gesperrt.

Lesesperre (gemeinsame Sperre):
	Für dieselben Daten können mehrere Lesevorgänge gleichzeitig ausgeführt werden, ohne dass die Schreibsperren (exklusive Sperren) der anderen beteiligt sind:
	Bis der Vorgang abgeschlossen ist, werden andere Schreib- und Lesesperren blockiert

Vor der Ausführung einer Abfrageanweisung (select) sperrt MyISAM automatisch alle beteiligten Tabellen. Vor der Ausführung eines Aktualisierungsvorgangs (aktualisieren, löschen, einfügen usw.) fügt es den beteiligten Tabellen automatisch eine Schreibsperre hinzu. Dieser Vorgang erfordert kein Eingreifen des Benutzers. Daher müssen Benutzer im Allgemeinen nicht direkt den Befehl LOCK TABLE verwenden, um die MyISAM-Tabelle explizit zu sperren.

Lesesperre hinzufügen:
	Sperrtabelle Tabellenname lesen; 
	---Tabellen entsperren;
Schreibsperre hinzufügen:
	Tabelle sperren Tabellenname schreiben;
	Fügen Sie eine Schreibsperre hinzu. Die aktuelle Sitzung kann lesen und schreiben, und andere Sitzungen werden blockiert (warten). Lesesperren schränken das Schreiben ein, und Schreibsperren schränken das Lesen und Schreiben ein.

1. Lesevorgänge auf MyISAM-Tabellen blockieren nicht die Leseanforderungen anderer Benutzer für dieselbe Tabelle, blockieren jedoch die Schreibanforderungen für dieselbe Tabelle.
2. Schreibvorgänge auf MyISAM blockieren die Lese- und Schreibvorgänge anderer Benutzer auf Tabelle 1.
3. Die Sperrplanung von MyISAM erfolgt zuerst nach dem Schreibprinzip.
	Es ist nicht als Haupttabelle geeignet. Nach dem Schreiben der Sperre erschweren eine große Anzahl von Aktualisierungen durch andere Threads die Abfrage, die Sperre zu erhalten, was zu einer dauerhaften Blockierung führen kann.

Überprüfen Sie die Verwendung von Sperren, um offene Tabellen anzuzeigen.
Überprüfen Sie den Sperrstatus der Tabelle, zeigen Sie einen Status wie „table_locks%“ an.
		Table_locks_immediate: Die Häufigkeit, mit der eine Sperre auf Tabellenebene erworben werden kann. Der Wert erhöht sich bei jedem sofortigen Sperrenerwerb um 1.
		Table_locks_waited: Die Anzahl der Wartezeiten, wenn Sie die Sperre nicht sofort erhalten können. Der Wert erhöht sich bei jeder Wartezeit um 1. Damit lässt sich die Schwere von Sperrkonflikten auf Tabellenebene bestimmen.	

Gemeinsam genutzte Schlösser:
	Auch als Lesesperre bekannt. Mehrere Transaktionen können eine Sperre gemeinsam nutzen, können aber nur exklusive Sperren lesen, nicht schreiben:
	Sperren, auch als Schreibsperre bekannt, werden nicht gemeinsam genutzt. Transaktionen, die keine Sperren erhalten können, können keine Lese- und Schreibvorgänge ausführen. Wenn Update-, Lösch- und Einfügeanweisungen ausgeführt werden, fügt innoDB den betreffenden Datensätzen automatisch exklusive Sperren hinzu. Anderen Select-Anweisungen werden keine Sperren hinzugefügt. Abfragen werden explizit Sperren hinzugefügt. Gemeinsam genutzte Sperren hinzufügen:
		select * from table_name where ... Sperren im Freigabemodus
	Fügen Sie eine exklusive Sperre hinzu:
		Wählen Sie * aus Tabellenname, wobei ... FÜR UPDATE

Indexfehler, Zeilensperre wird zu Tabellensperre aktualisiert, wenn kein Index dahinter steht, wird auch zu Tabellensperre aktualisiert

Status wie „innodb_row_lock%“ anzeigen;
	Innodb_row_lock_current_waits Die Anzahl der aktuell wartenden Sperren. Innodb_row_lock_time Die Gesamtdauer der Sperre. Innodb_row_lock_time_avg Die durchschnittliche Dauer der Sperre. Innodb_row_lock_time_max Die maximale Dauer der Sperre. Innodb_row_lock_waits Die Gesamtzahl der Wartezeiten seit dem Systemstart.

Versuchen Sie, alle Datenabrufe über Indizes durchzuführen, um zu vermeiden, dass Zeilensperren ohne Index zu Tabellensperren aufgewertet werden. Entwerfen Sie Indizes sinnvoll und minimieren Sie den Umfang der Sperren. Minimieren Sie Indexbedingungen und Indexbereiche, um Lückensperren zu vermeiden. Versuchen Sie, die Transaktionsgröße zu kontrollieren und die Menge der gesperrten Ressourcen und die Dauer zu reduzieren. Verwenden Sie so weit wie möglich eine Transaktionsisolierung auf niedriger Ebene (Geschäftsanforderungen müssen erfüllt werden).