Një transaksion i grupon deklaratat në një njësi atomike: ose të gjitha bëjnë commit ose të gjitha bëjnë rollback, duke dhënë A, C, I, D e ACID. Isolation level e rregullon "I"-në — sa shumë transaksionet konkurrente mund të shohin nga të dhënat e pa-commit-uara ose në ndryshim të njëri-tjetrit.
| Niveli | Dirty read | Non-repeatable read | Phantom |
|---|
| READ UNCOMMITTED | e mundur | e mundur | e mundur |
| READ COMMITTED | jo | e mundur | e mundur |
| REPEATABLE READ (parazgjedhja e InnoDB) | jo | jo | kryesisht jo* |
| SERIALIZABLE | jo | jo | jo |
*REPEATABLE READ i InnoDB përdor MVCC (çdo transaksion lexon një snapshot konsistent) plus next-key locks, kështu që bllokon edhe shumicën e phantom-eve — më i fortë se sa kërkon standardi SQL.
SELECT @@transaction_isolation; -- REPEATABLE-READ si parazgjedhje
START TRANSACTION;
SELECT balance FROM accounts WHERE id = 1; -- snapshot merret këtu
UPDATE accounts SET balance = balance - 100 WHERE id = 1;
UPDATE accounts SET balance = balance + 100 WHERE id = 2;
COMMIT; -- të dyja update-t aplikohen, ose ROLLBACK i zhbën të dyja
Mbaje parazgjedhjen e InnoDB (REPEATABLE READ) veç nëse ke një arsye. READ COMMITTED (ajo që Postgres/Oracle kanë si parazgjedhje) redukton lock contention për sisteme me shumë shkrime; SERIALIZABLE është korrekt por serializon punën konfliktuale dhe mund të bëjë më shumë deadlock.
Isolation është butoni mes korrektësisë dhe konkurrencës. Të kuptosh këto anomali të lejon të shpjegosh bug-e si "totali s'doli i saktë nën ngarkesë" dhe të zgjedhësh një nivel që i mban transaksionet që lëvizin para korrekte pa mbytur pa nevojë throughput-in.
Një bibliotekë pyetjesh intervistash IT me përgjigje të detajuara — nga Junior te Senior.
Dhuro