ਇੱਕ transaction statements ਨੂੰ ਇੱਕ atomic unit ਵਿੱਚ ਸਮੂਹਬੱਧ ਕਰਦਾ ਹੈ: ਜਾਂ ਤਾਂ ਸਾਰੇ commit ਹੁੰਦੇ ਹਨ ਜਾਂ ਸਾਰੇ roll back ਹੁੰਦੇ ਹਨ, ਜੋ ACID ਦਾ A, C, I, D ਦਿੰਦਾ ਹੈ। isolation level "I" ਨੂੰ tune ਕਰਦਾ ਹੈ — concurrent transactions ਇੱਕ-ਦੂਜੇ ਦੇ uncommitted ਜਾਂ ਬਦਲਦੇ ਡੇਟਾ ਨੂੰ ਕਿੰਨਾ ਦੇਖ ਸਕਦੇ ਹਨ।
| Level | Dirty read | Non-repeatable read | Phantom |
|---|
| READ UNCOMMITTED | ਸੰਭਵ | ਸੰਭਵ | ਸੰਭਵ |
| READ COMMITTED | ਨਹੀਂ | ਸੰਭਵ | ਸੰਭਵ |
| REPEATABLE READ (InnoDB default) | ਨਹੀਂ | ਨਹੀਂ | ਜ਼ਿਆਦਾਤਰ ਨਹੀਂ* |
| SERIALIZABLE | ਨਹੀਂ | ਨਹੀਂ | ਨਹੀਂ |
*InnoDB ਦਾ REPEATABLE READ MVCC (ਹਰ transaction ਇੱਕ consistent snapshot ਪੜ੍ਹਦਾ ਹੈ) ਦੇ ਨਾਲ next-key locks ਵਰਤਦਾ ਹੈ, ਇਸ ਲਈ ਇਹ ਜ਼ਿਆਦਾਤਰ phantoms ਨੂੰ ਵੀ ਰੋਕ ਦਿੰਦਾ ਹੈ — SQL standard ਦੀ ਲੋੜ ਤੋਂ ਵੱਧ ਮਜ਼ਬੂਤ।
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
InnoDB ਦਾ default (REPEATABLE READ) ਰੱਖੋ ਜਦੋਂ ਤੱਕ ਤੁਹਾਡੇ ਕੋਲ ਕੋਈ ਕਾਰਨ ਨਾ ਹੋਵੇ। READ COMMITTED (ਜੋ Postgres/Oracle ਦਾ default ਹੈ) high-write systems ਲਈ lock contention ਘਟਾਉਂਦਾ ਹੈ; SERIALIZABLE ਸਹੀ ਹੈ ਪਰ conflicting ਕੰਮ ਨੂੰ serialize ਕਰਦਾ ਹੈ ਅਤੇ ਜ਼ਿਆਦਾ deadlock ਕਰ ਸਕਦਾ ਹੈ।
Isolation correctness ਅਤੇ concurrency ਵਿਚਕਾਰ ਦਾ dial ਹੈ। ਇਹਨਾਂ anomalies ਨੂੰ ਸਮਝਣਾ ਤੁਹਾਨੂੰ "load ਹੇਠ total ਸਹੀ ਨਹੀਂ ਜੁੜਿਆ" ਵਰਗੇ bugs ਸਮਝਾਉਣ ਦਿੰਦਾ ਹੈ ਅਤੇ ਇੱਕ ਅਜਿਹਾ level ਚੁਣਨ ਦਿੰਦਾ ਹੈ ਜੋ ਪੈਸੇ-ਵਾਲੀਆਂ transactions ਨੂੰ ਸਹੀ ਰੱਖੇ ਬਿਨਾਂ throughput ਨੂੰ ਬੇਲੋੜਾ ਦਬਾਏ।
ਵਿਸਤ੍ਰਿਤ ਜਵਾਬਾਂ ਨਾਲ IT ਇੰਟਰਵਿਊ ਸਵਾਲਾਂ ਦੀ ਇੱਕ ਲਾਇਬ੍ਰੇਰੀ — ਜੂਨੀਅਰ ਤੋਂ ਸੀਨੀਅਰ ਤੱਕ।
ਦਾਨ ਕਰੋ