---
title: "Transaction İzolasyon Seviyeleri: Kirli Okuma, Kilitlenme ve Gerçek Hayat"
url: "https://cilginyazilim.com/blog/transaction-izolasyon-seviyeleri-pratikte"
description: "Read committed, repeatable read ve serializable arasındaki gerçek farklar: kirli okuma, hayalet satır, kilit bekleme, deadlock ve stok düşme senaryoları."
published: "2026-08-05T18:00:00+03:00"
modified: "2026-08-06T00:18:38+03:00"
author: "superadmin"
category: "Veritabanı ve Performans"
tags: ["veritabanı", "mysql", "performans", "izolasyon seviyeleri", "transaction", "deadlock", "kilitleme", "eşzamanlılık", "repeatable read", "kirli okuma", "veri tutarlılığı", "innodb", "stok yönetimi"]
site: "CılgınYazılım"
language: "tr"
---

# Transaction İzolasyon Seviyeleri: Kirli Okuma, Kilitlenme ve Gerçek Hayat

Aynı anda iki kullanıcı aynı satıra dokunduğunda ne olur? Cevap, çoğu ekibin hiç ayarlamadığı bir seviyede saklı.

Veritabanı **izolasyon seviyeleri**, çoğu projede hiç dokunulmayan ama sessizce her satırı etkileyen bir ayardır. Tek kullanıcılı bir test ortamında hiçbir fark yaratmaz; yoğun saatte iki kullanıcı aynı stok satırına aynı anda dokunduğunda ise fark, satılmayan bir ürün ya da iki kez satılan son stok olarak ortaya çıkar. Bu yazıda seviyeleri teorik tablolarla değil, gerçek senaryolarla ele alıyoruz.

![İzolasyon seviyeleri karşılaştırma listesi](https://cilginyazilim.com/uploads/blog/2026/08/transaction-izolasyon-seviyeleri-pratikte-ozet.png)
*Daha yüksek izolasyon daha çok doğruluk değil, daha çok bekleme demektir.*

## Sorun: eşzamanlılık anormallikleri

İzolasyon seviyeleri, aynı anda çalışan işlemlerin birbirini ne kadar görebileceğini belirler. Engellemeye çalıştıkları üç temel anormallik vardır.

- **Kirli okuma:** Henüz tamamlanmamış (commit edilmemiş) bir değişikliği okumak. Diğer işlem geri alınırsa, hiç var olmamış bir veriye göre karar vermiş olursunuz.
- **Tekrarlanamayan okuma:** Aynı işlem içinde aynı satırı iki kez okuduğunuzda farklı değer görmek. Rapor üretirken toplamların tutmamasının klasik sebebidir.
- **Hayalet satır:** Aynı koşulu iki kez sorguladığınızda ikinci seferde yeni satırların belirmesi. Sayım ve toplam hesaplarında sinsi hatalar üretir.

## Seviyeler ve pratikteki karşılıkları

### Read committed

PostgreSQL'in ve pek çok sistemin varsayılanıdır. Yalnızca tamamlanmış veriyi okursunuz; kirli okuma ortadan kalkar. Ancak aynı işlem içinde ikinci okuma farklı sonuç verebilir. Web uygulamalarının büyük kısmı için makul bir varsayılandır: kilit süreleri kısa, eşzamanlılık yüksektir.

### Repeatable read

MySQL/InnoDB varsayılanıdır. İşlem başladığı anın tutarlı bir görüntüsünü görürsünüz; aynı satırı kaç kez okursanız okuyun aynı değeri alırsınız. Çok adımlı raporlar ve tutarlılık gerektiren okuma işlemleri için uygundur. Bedeli, uzun süren işlemlerin veritabanına eski sürüm verisini daha uzun süre tutturmasıdır — uzun açık kalan işlemler bu yüzden performans sorunu üretir.

### Serializable

İşlemler sanki sırayla çalışmış gibi davranır; tüm anormallikler ortadan kalkar. Bedeli ağırdır: kilit çakışmaları ve işlem geri alınmaları belirgin biçimde artar. Yüksek trafikli bir sistemde tüm işlemleri bu seviyeye almak, doğruluk kazandırmaz — çoğu zaman zaman aşımı ve hata üretir.

## Asıl tuzak: kayıp güncelleme

Sahada en pahalı hata, yukarıdaki üçünden hiçbiri değildir. Şu kod, izolasyon seviyesinden bağımsız olarak yanlıştır:

```
-- İki istek aynı anda çalışırsa biri diğerini ezer
SELECT stok FROM urunler WHERE id = 42;   -- 1 okundu
-- uygulama tarafında: 1 - 1 = 0
UPDATE urunler SET stok = 0 WHERE id = 42;
```

İki istek de "1" okur, ikisi de "0" yazar ve iki adet satılır. Çözüm izolasyon seviyesini yükseltmek değildir; işi veritabanına yaptırmaktır:

```
UPDATE urunler SET stok = stok - 1
WHERE id = 42 AND stok >= 1;
-- etkilenen satır 0 ise stok yetersizdi
```

Karar için okumanız şartsa, satırı açıkça kilitleyin (`SELECT ... FOR UPDATE`). Bu, "önce oku sonra yaz" desenini güvenli hâle getiren tek yoldur.

## Deadlock: kaçınılmaz, ama yönetilebilir

İki işlem birbirinin kilidini beklediğinde veritabanı birini iptal eder. Bu bir arıza değil, normal bir sonuçtur — uygulamanın bu hatayı yakalayıp işlemi yeniden denemesi gerekir.

Sıklığı azaltmanın üç pratik yolu vardır: satırlara her zaman aynı sırada dokunmak (örneğin id sırasına göre), işlemleri mümkün olduğunca kısa tutmak ve işlem içinde *asla* dış servis çağrısı yapmamak. Sonuncusu en çok atlanan kuraldır: bir HTTP çağrısı işlem içinde beklerken tüm kilitler tutulmaya devam eder ve yavaş bir dış servis, veritabanı kilit fırtınasına dönüşür — bu tam olarak [dayanıklı API entegrasyonu](https://cilginyazilim.com/blog/ucuncu-parti-api-entegrasyonunda-dayaniklilik) yazımızda anlattığımız yayılma etkisidir.

## Uzun işlemlerin görünmeyen maliyeti

Bir işlem açıkken çalışan her sorgu kilit tutar ve eski veri sürümlerinin saklanmasını zorunlu kılar. Uygulama tarafında "işlemi başta açıp sonunda kapatmak" pratik görünür, ancak arada yapılan dosya yükleme veya e-posta gönderme adımları işlemi dakikalarca açık tutabilir. Kural nettir: işlem yalnızca veritabanı yazmalarını kapsamalı, yan etkiler dışarıda kalmalıdır.

Bu tür yavaşlıkların tespiti için sorgu planı okumak gerekir; [EXPLAIN nasıl okunur](https://cilginyazilim.com/blog/indeks-var-sorgu-yavas-explain-nasil-okunur) yazımız bu konuda pratik bir başlangıçtır. Kilit sorunları çoğu zaman eksik indeksle birleşir: indekssiz bir `UPDATE ... WHERE`, beklenenden çok daha fazla satırı kilitleyebilir; temel için [indeks mantığı](https://cilginyazilim.com/blog/veritabani-index-mantigi-yavas-sorgular-nasil-hizlanir) yazımıza bakabilirsiniz.

## Pratik kurallar

1. Varsayılan seviyeyi bilmeden bırakmayın; hangi veritabanında hangi seviyenin varsayılan olduğunu öğrenin.
2. ORM kullanıyorsanız üretilen SQL'i mutlaka görün; soyutlamanın nerede sızdığını [ORM mi ham SQL mi](https://cilginyazilim.com/blog/orm-mi-ham-sql-mi-soyutlamanin-siniri) yazımızda ele alıyoruz.
3. Tüm uygulamayı yüksek izolasyona almak yerine, yalnızca kritik işlemlerde açık kilit kullanın.
4. Sayaç ve stok gibi alanlarda okuma-hesaplama-yazma yerine tek ifadeli koşullu güncelleme kullanın.
5. Deadlock hatasını yakalayıp sınırlı sayıda yeniden deneyin; bu hatayı istisnai bir arıza gibi ele almayın.
6. İşlemleri kısa tutun ve içine dış çağrı koymayın.

Şema değişiklikleri sırasında kilit davranışı ayrıca önem kazanır; [sıfır kesintili göç](https://cilginyazilim.com/blog/veritabani-gocleri-sifir-kesintiyle-nasil-uygulanir) yazımız bu konuyu ayrıntılandırıyor. Motorun kilitleme ayrıntıları için [MySQL resmi dokümantasyonu](https://dev.mysql.com/doc/) kesin referanstır.

## Sonuç

İzolasyon seviyeleri, doğruluk ile eşzamanlılık arasındaki takası ayarlar; daha yükseği her zaman daha iyisi değildir. Pratikte en çok zarar veren hata, seviye seçimi değil "önce oku sonra yaz" desenidir ve çözümü koşullu tek ifadeli güncelleme ya da açık satır kilididir. İşlemleri kısa tutmak, dış çağrıları dışarıda bırakmak ve deadlock'u normal bir sonuç kabul edip yeniden denemek, eşzamanlılık kaynaklı sorunların büyük kısmını ortadan kaldırır. Bugün kod tabanınızda bir arama yapın: kaç yerde bir değeri okuyup uygulama tarafında hesaplayıp geri yazıyorsunuz? İşte olası kayıp güncellemeleriniz orada.

## Sıkça Sorulan Sorular

### İzolasyon seviyesini yükseltmek veriyi garanti eder mi?

Hayır. En sık görülen hata olan kayıp güncelleme, tipik seviyelerin hiçbiri tarafından engellenmez. Bunun için koşullu güncelleme veya açık satır kilidi gerekir.

### Deadlock olması sistemin bozuk olduğunu mu gösterir?

Hayır, eşzamanlı sistemlerde beklenen bir sonuçtur. Sorun, uygulamanın bu hatayı yakalayıp yeniden denememesidir. Sıklığı çok yüksekse işlem sırası ve işlem süresi gözden geçirilmelidir.

### İşlem içinde e-posta göndermek neden kötü?

İşlem açık kaldığı sürece kilitler tutulur. Yavaş bir SMTP sunucusu, veritabanında bekleyen sorgular zincirine yol açar. Yan etkiler işlem tamamlandıktan sonra, tercihen kuyruk üzerinden yapılmalıdır.

### Repeatable read kullanan bir sistemde rapor tutarlılığı garanti midir?

Tek bir işlem içindeki okumalar için evet, tutarlı bir görüntü görürsünüz. Ancak rapor birden çok işleme yayılıyorsa bu garanti kalkar; uzun raporlarda okumaların tek işlemde yapılması gerekir.

---

Kaynak: [Transaction İzolasyon Seviyeleri: Kirli Okuma, Kilitlenme ve Gerçek Hayat](https://cilginyazilim.com/blog/transaction-izolasyon-seviyeleri-pratikte)