Ich habe dies mit MySQL Server 5.5 versucht:
1) sichergestellt, dass Transaktionsisolationsebene wiederholbar_read
ist2) hat shell-1 gestartet, eine Transaktion gestartet und dann einen Wert über select
gelesen3) hat shell-2 gestartet, eine Transaktion gestartet und dann den gleichen Wert über select
gelesen4) in Shell-1, aktualisiert den Wert auf Wert + 1 und committed
5) in Shell-2, aktualisiert den Wert auf Wert + 1 und committed
Der Wert hat eine seiner Aktualisierungen verloren und wurde nur um 1 erhöht.
Nun, wie ich es verstehe, verwendet RR shared read locks und exclusive write locks, was bedeutet, dass die Transaktionen in # 4 und # 5 oben dead-locked haben sollten, aber das ist nicht passiert.
Entweder ist mein Verständnis von RR fehlerhaft oder MySQL implementiert RR auf andere Weise. Also was ist es?
BEARBEITEN: Durch ein ähnliches Experiment wurde auch bestätigt, dass eine RR-Transaktion (t1) keine Zeilen in dieselbe Tabelle durch eine andere RR-Transaktion (t2) eingefügt hat, wenn sie eine weitere Auswahl in dieser Tabelle ausführt, selbst nachdem t2 committed und bevor t1 begeht. (Hier ist der Link zu diesem Experiment: Ссылка )
Bedeutet das, dass die RR von MySQL auch Phantom-Lesevorgänge übernimmt?
MySQL entspricht nicht wirklich Repeatable Read. Sie können dies erzwingen, indem Sie die Isolationsstufe serialisierbar verwenden oder ein FOR UPDATE nach Ihren Selects setzen (siehe Beispiel unten). Dann wird das gewünschte Verhalten erreicht. In Bezug auf Phantom-Lesevorgänge ist MySQL tatsächlich strenger als notwendig ...
%Vor%Tags und Links mysql transactions isolation-level