Document ID: /fineweb-2-swissfilter-quality_10-filterrobots/filtered/03255.jsonl.gz/1891

...
UNLOCK TABLES
LOCK TABLES sperrt eine ganzeTabelle für den Thread, also für den Prozeß, der geradeauf die Tabelle zugreift. UNLOCK TABLES entsperrtdie Tabelle und gibt diese für andere Threads frei. AlleTabellen, die gesperrt sind, werden automatisch entsperrt,wenn dieser Thread eine andere Tabelle sperrt, oder dieVerbindung zum Server löst.
Wenn ein Thread eine READ Sperre setzt, dann kann dieserund alle andere Threads (!) nur aus dieser Tabelle lesen.Also merke: Ein WRITE Lock sperrt andere Threads fürLese-und Schreibvorgänge, ein READ Lock ermöglicht immernoch das Lesen für alle Threads.
Jeder Thread wartet solange auf seinen Einsatz, bis eralle angeforderten Locks auch zugewiesen bekommt (was langedauern kann).
WRITE LOCKS haben normalerweise einehöhere Priorität vor READ LOCKS.
Damit wird sichergestellt, daß alle Updates so schnell
wie möglich eingespielt werden, und die Clients (die eingebenden
Personen) nicht mit unnötigen Wartezeiten zu kämpfen haben.
Das bedeutet, daß wenn ein Thread einen READ LOCK zugewiesen
bekommt, und ein anderer Thread einen WRITE LOCK angefordert,
dann werden die Lesezugriffe solange zurückgestellt, bis
der Thread den WRITE LOCK erhalten und seine Schreibprozesse
beendet hat. WRITE LOCKS kann man aber auch in der Priorität
zurücksetzen. Dies geschieht mit Hilfe der Option: LOW_PRIORITY
WRITE.
Damit wird der Datenbankserver veranlaßt, nur in Lesepausen
die Schreibvorgänge durchzuführen. Dies ist u.a. für Internet
Anwendungen interessant. Es muß aber sichergestellt sein,
daß es auch tatsächlich Pausen gibt, wo die Schreibvorgänge
eingeschoben werden können.
Bei dem Einsatz des Befehls LOCK TABLES muß für alle
Tabellen, die in einem Statement abgefragt werden, jeweils
ein Lock gesetzt werden. Wenn also eine Tabelle mit mehrfachen
ALIAS abgefragt wird, dann muß für jeden ALIAS ein LOCK
gesetzt werden. Diese Vorgehensweise dient dazu, die Datenbank
von DEADLOCKS freizuhalten.
Man sollte jedoch keinesfalls Tabellen mit einem WRITE
LOCK belegen, wenn der Befehl INSER DELAYED verwendet wird.
Hierzu muß man wissen, daß MySQL den INSERT Befehl
einem neuen THREAD zuordnet.
Normalerweise ist ein Lock auf eine Tabelle bei einem
einzelnen UPDATE Statement nicht notwendig. Der Grund liegt
darin, daß Schreibvorgänge niemals mit Abfragevorgängen
kollidieren können, da sie jeweils einen Thread zugewiesen
bekommen. Es gibt nur ein paar wenige Fälle, bei denen Tabellen
mit einem Lock gesperrt werden müssen, z.B. bei INSERT DELAYED,
damit kein SELECT Statement zwischen zwei UPDATE Vorgängen
eingeschoben werden kann. Dies würde zu Inkonsistenzen der
Tabellen führen.
Merke: Bei der Änderung der Hierarchien von Lese-oder
Schreibvorgängen mit ... DELAYED ...., oder durch Änderung
der Hierarchie mit Parametern beim Start des
mysqld Datenbank - Servers,
müssen eventuell alle SELECT Statements mit LOCKS versehen
werden !