472 MySQL - Technische Referenz f¨ur Version 5.0.1-alpha
Wenn ein Thread eine READ-Sperre auf eine Tabelle erlangt, kann dieser Thread (und alle
anderen Threads) nur aus der Tabelle lesen. Wenn ein Thread eine WRITE-Sperre auf eine
Tabelle erlangt, kann nur der Thread, der die Sperre veranlasst hat, READ oder WRITE auf
der Tabelle durchf¨uhren. Andere Threads werden blockiert.
Der Unterschied zwischen READ LOCAL und READ ist, dass READ LOCAL nicht kollidierende
INSERT-Statements w¨ahrend der Dauer der Sperre zul¨aßt. Das kann jedoch nicht benutzt
werden, wenn Sie Datenbankdateien ausserhalb von MySQL bearbeiten, w¨ahrend die Sperre
aktiv ist.
Wenn Sie LOCK TABLES benutzen, m¨ussen Sie alle Tab ellen sperren, die Sie benutzen werden,
und Sie m¨ussen denselben Alias benutzen, den Sie in Ihren Anfragen benutzen werden!
Wenn Sie eine Tabelle in einer Anfrage mehrfach (mit Aliasen) benutzen, m¨ussen Sie f¨ur
jeden Alias eine Sperre machen!
WRITE-Sperren haben normalerweise h¨ohere Priorit¨at als READ-Sperren, um sicherzustellen,
dass Aktualisierungen so fr¨uh wie m¨oglich bearbeitet werden. Dass heißt, wenn ein Thread
eine READ-Sperre erlangt und dann ein anderer Thread eine WRITE-Sp erre verlangt, dass
nachfolgende READ-Sperrenanfragen warten, bis der WRITE-Thread die Sperre erhalten und
freigegeben hat. Sie k¨onnen LOW_PRIORITY WRITE-Sperren benutzen, um anderen Threads
zu gestatten, READ-Sperren zu erlangen, w¨ahrend der Thread auf die WRITE-Sperre wartet.
Sie sollten nur dann LOW_PRIORITY WRITE-Sperren benutzen, wenn Sie sicher sind, dass es
irgendwann eine Zeit gibt, in der kein anderer Thread eine READ-Sperre haben wird.
LOCK TABLES funktioniert wie folgt:
1. Sortiert alle Tabellen, die gesperrt werden sollen, in einer intern definierten Reihenfolge
(aus Benutzersicht ist die Reihenfolge undefiniert).
2. Wenn eine Tabelle mit einer Lese- und einer Schreibsperre gesperrt ist, wird die Schreib-
sperre vor die Lesesperre platziert.
3. Sperrt eine Tabelle nach der anderen, bis der Thread alle Sperren erhalten hat.
Diese Methode stellt sicher, dass Tabellensperren blockierungsfrei ist. Bei diesem Schema
gibt es jedoch ein paar weitere Dinge, derer man sich bewusst sein muss:
Wenn Sie eine LOW_PRIORITY_WRITE-Sperre f¨ur eine Tabelle benutzen, heißt das, dass
MySQL auf diese bestimmte Sperre wartet, bis es keinen Thread gibt, der eine READ-Sperre
will. Wenn der Thread die WRITE-Sperre erhalten hat und darauf wartet, die Sperre f¨ur die
n¨achste Tabelle in der Tabellensperrliste zu erhalten, warten alle anderen Threads darauf,
dass die WRITE-Sperre aufgehoben wird. Wenn das bei Ihrer Applikation zu ernsthaften
Problemen f¨uhrt, sollten Sie in Betracht ziehen, einige Ihrer Tabelle in transaktionssichere
Tabelle umzuwandeln.
Es ist sicher, einen Thread mit KILL zu killen, der auf eine Tabellensperre wartet. Siehe
Abschnitt 5.5.4 [KILL], Seite 242.
Beachten Sie, dass Sie NICHT irgend welche Tabellen sperren sollten, die Sie mit INSERT
DELAYED benutzen. Das liegt darin, dass in diesem Fall das INSERT von einem separaten
Thread durchgef¨uhrt wird.
Normalerweise m¨ussen Sie Tabellen nicht sperren, weil alle einzelnen UPDATE-Statements
atomisch sind. Kein anderer Thread kann mit einem aktuell ausgef¨uhrten SQL-Statement
in die Quere kommen. Es gibt dennoch einige F¨allen, in denen es w¨unschenswert sein kann,
Tabellen zu sperren:
Comentarios a estos manuales