Bir transaction, ifadeleri tek bir atomik birime gruplar: ya hepsi commit olur ya da hepsi geri alınır, ki bu ACID'in A, C, I, D'sini verir. Isolation level, "I"yi ayarlar — eşzamanlı transaction'ların birbirlerinin commit edilmemiş veya değişen verilerini ne kadar görebileceğini.
| Seviye | Dirty read | Non-repeatable read | Phantom |
|---|
| READ UNCOMMITTED | mümkün | mümkün | mümkün |
| READ COMMITTED | hayır | mümkün | mümkün |
| REPEATABLE READ (InnoDB varsayılanı) | hayır | hayır | çoğunlukla hayır* |
| SERIALIZABLE | hayır | hayır | hayır |
*InnoDB'nin REPEATABLE READ'i MVCC (her transaction tutarlı bir snapshot okur) artı next-key lock'lar kullanır, bu yüzden çoğu phantom'u da bloklar — SQL standardının gerektirdiğinden daha güçlü.
SELECT @@transaction_isolation; -- REPEATABLE-READ by default
START TRANSACTION;
SELECT balance FROM accounts WHERE id = 1; -- snapshot taken here
UPDATE accounts SET balance = balance - 100 WHERE id = 1;
UPDATE accounts SET balance = balance + 100 WHERE id = 2;
COMMIT; -- both updates apply, or ROLLBACK undoes both
Bir nedeniniz olmadıkça InnoDB varsayılanını (REPEATABLE READ) koruyun. READ COMMITTED (Postgres/Oracle'ın varsayılanı) yazma ağırlıklı sistemler için kilit çekişmesini azaltır; SERIALIZABLE doğrudur ancak çakışan işi serileştirir ve daha çok deadlock yapabilir.
Isolation, doğruluk ile eşzamanlılık arasındaki ayardır. Bu anomalileri anlamak, "yük altında toplam tutmadı" gibi hataları açıklamanızı ve para taşıyan transaction'ları throughput'u gereksiz yere kısmadan doğru tutan bir seviye seçmenizi sağlar.
Junior'dan Senior'a detaylı cevaplarla bir BT mülakat soruları kütüphanesi.
Bağış Yap