Cevap

İşlem izolasyonu, eşzamanlı işlemlerin birbirinin değişikliklerini nasıl gördüğünü etkiler. Bu, ACID özelliklerinin önemli bir parçasıdır. ANSI SQL'de dört temel izolasyon seviyesi bulunmaktadır:

• READ UNCOMMITTED — Diğer işlemlerin henüz onaylanmamış değişikliklerini bile görür (kirli okumalar, dirty reads).
• READ COMMITTED — Sadece onaylanmış değişiklikleri görür; kirli okumaları engeller, ancak tekrar edilemeyen okumalar (non-repeatable reads) yapabilir.
• REPEATABLE READ — Aynı işlemin içinde aynı veriler değişmeden görülür. Kirli ve tekrar edilemeyen okumaları önler, ancak hayalet okumalar (phantom reads) mümkün olabilir.
• SERIALIZABLE — En katı seviyedir, işlemler tamamen birbirinden izolesidir, sanki sırayla çalışıyormuş gibi; tüm anomali türlerini ortadan kaldırır.

Seçim, uygulamanın gereksinimlerine bağlıdır:

• Raporlama için genellikle REPEATABLE READ veya üstü yeterlidir;
• Yüksek yük sistemleri için optimal uzlaşma — READ COMMITTED;
• Finans için — SERIALIZABLE, performans kaybına rağmen.

Örnek:

SET TRANSACTION ISOLATION LEVEL REPEATABLE READ;
BEGIN;
-- Sonraki SELECT'ler "dondurulmuş" değerleri görecektir

Kandırmaca Soru

"REPEATABLE READ seviyesi herhangi bir DB'de hayalet okumaları önleyebilir mi?"

Hayır. PostgreSQL ve bazı diğer veritabanlarında REPEATABLE READ seviyesi sadece kirli ve tekrar edilemeyen okumaları önler, ancak mutlaka hayalet okumalardan korumaz. MySQL/InnoDB'de REPEATABLE READ temelde SERIALIZABLE'dır, ancak diğer veritabanlarında değildir.

Örnek:

-- Bir işlem içinde SELECT * FROM orders WHERE amount > 100; okuyoruz;
-- Diğer bir işlemde amount > 100 olan yeni bir değer ekleniyor ve onaylanıyor
-- İlk işlem yeniden SELECT yaparken "hayalet" bir satırı görecektir, eğer izolasyon SERIALIZABLE'dan düşükse

Konu ile ilgili bilgilere sahip olmamanın gerçek hatalarına dair örnekler

---

Hikaye

Finans hizmeti yalnızca READ COMMITTED'i performans için kısıtladı — kullanıcı başka bir işlem tarafından değiştirilen bir tutarı gördü, bakiye farklılıkları ortaya çıktı.

---

Hikaye

Otel rezervasyon sisteminde aynı odanın çift rezervasyonu yapıldı — işlemler güncel rezervasyonların çıktısını izole etmedi, seviye READ COMMITTED idi.

---

Hikaye

MySQL'den PostgreSQL'e geçiş: Geliştirici REPEATABLE READ'in hayaletlerden koruduğunu düşündü, ancak geçiş sonrası bir işlemin içinde beklenmedik "askıda" siparişler görüldü.