510 MySQL - Technische Referenz f¨ur Version 5.0.1-alpha
• DELETE FROM ... WHERE ... setzt ein exklusives N¨achsten-Schl¨ussel-Sperren auf jeden
Datensatz, der beim Suchen gefunden wird.
• Wenn auf der Tabelle eine FOREIGN KEY-Beschr¨ankung definiert ist, setzt
jedes Einf¨ugen, Aktualisieren oder L¨oschen, was die
¨
Uberpr¨ufung der
Beschr¨ankungsbedingung erfordert, gemeinsam genutzte (shared) Sperren auf
Datensatzebene auf die Datens¨atze, die bei der
¨
Uberpr¨ufung der Beschr¨ankung
betrachtet werden. Auch im Falle, dass die Beschr¨ankung fehlschl¨agt, setzt InnoDB
diese Sperren.
• LOCK TABLES ... : setzt Tabellensperren. In der Implementation setzt die MySQL-
Ebene des Codes diese Sperren. Die automatische Blockierungserkennung von InnoDB
kann keine Blockierungen bemerken, bei denen solche Tabellensperren involviert sind,
siehe n¨achster Abschnitt weiter unten. Sehen Sie auch im Abschnitt 13 (’InnoDB-
Einschr¨ankungen’) wegen folgendem nach: Weil MySQL keine Sperren auf Zeilenebene
erkennt, ist es m¨oglich, dass Sie eine Sperre auf eine Tabelle erhalten, auf der ein
anderer Benutzer momentan Sperren auf Zeilenebene hat. Das gef¨ahrdet allerdings
nicht die Transaktionsintegrit¨at.
8.5.8.5 Blockierungserkennung und Rollback
InnoDB erkennt automatisch eine Blockierung von Transaktionen und rollt die Transaktion
zur¨uck, deren Sp erranforderung diejenige war, die die Blockierung aufbaute, also einen Kreis
im Warte-Diagramm von Transaktionen. InnoDB kann keine Blockierungen erkennen, bei
denen eine Sperre im Spiel ist, die durch ein MySQL-LOCK TABLES-Statement verursacht
wurde, oder wenn eine Sperre durch einen anderen Tabellen-Handler als InnoDB gesetzt
wurde. Solche Situationen m¨ussen Sie mit innodb_lock_wait_timeout, das in ‘my.cnf’
gesetzt wird.
Wenn InnoDB ein komplettes Rollback einer Transaktion durchf¨uhrt, werden alle Sperren
der Transaktion aufgehoben. Wenn jedoch nur ein einzelnes SQL-Statement als Ergebnis
eines Fehlers zur¨uckgerollt wird, k¨onnen einige der Sperren, die durch das SQL-Statement
gesetzt wurde, verbleiben. Das liegt daran, dass InnoDB Zeilensperren in einem Format
speichert, die ihm unm¨oglich machen, im Nachhinein zu erkennen, welche Sperre durch
welches SQL-Statement gesetzt wurde.
8.5.8.6 Ein Beispiel, wie konsistentes Lesen bei InnoDB
funktioniert
Wenn Sie ein Konsistentes Lesen ausf¨uhren, also ein gew¨ohnliches SELECT-Statement, gibt
InnoDB Ihrer Transaktion einen Zeitpunkt (Timepoint), gem¨aß dem Ihre Anfrage die Daten-
bank sieht. Wenn daher Transaktion B eine Zeile l¨oscht und das wirksam wird (commit),
nachdem Ihr Zeitpunkt zugewiesen wurde, werden Sie die Zeile nicht als gel¨oscht sehen.
Gleiches gilt f¨ur Einf¨uge- und Aktualisierungsoperationen.
Sie k¨onnen Ihren Zeitpunkt ’vorstellen’, indem Sie Ihre Transaktion abschicken (commit)
und dann ein weiteres SELECT ausf¨uhren.
Das nennt sich Multiversioned Concurrency Control (multiversionierte Gleichzeitigkeitskon-
trolle):
Comentarios a estos manuales