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 !