Sorgunun anatomisi: Enter tuşuna basıldıktan sonra DBMS içinde neler olur?

Veritabanı işlemcisi (veya sorgu yürütme motoru), SQL sorgusu metnini düşük seviyeli veri okuma ve yazma işlemleri dizisine dönüştüren bir DBMS bileşenidir. Sözdizimsel analizden, indeksleri ve istatistikleri dikkate alarak en uygun yürütme planının oluşturulmasına ve verilerin bellekten veya diskten fiziksel olarak alınmasına kadar sorumludur. Bu süreci anlamak, geliştiricilerin daha etkili sorgular yazmasına ve performans darboğazlarından kaçınmasına olanak tanır.

SELECT * FROM users WHERE id = 1 gibi bir sorgu gönderdiğinizde, veritabanı sadece kaydı "aramaz". Karmaşık bir süreçten geçer: sözdizimini kontrol eder, erişim haklarını analiz eder, verileri elde etmenin onlarca olası yolunu değerlendirir ve en hızlısını seçer, ardından onu yürütür. Bu mekanizmayı adım adım inceleyelim.

Sorgu işleyicisi mimarisi

DBMS'nin iç yapısı (PostgreSQL, MySQL, Oracle veya SQL Server olsun) genellikle sorgu işlemeyi üç ana modüle ayırır:

1. Ayrıştırıcı (Parser) — dilin "anlaşılmasından" sorumludur. SQL sözdiziminde hata olup olmadığını ve belirtilen tabloların ve sütunların var olup olmadığını kontrol eder.
2. İyileştirici (Optimizer/Planner) — sistemin "beyni". Birkaç yürütme planı alternatifi oluşturur (örneğin, indeks kullanmak veya tüm tabloyu taramak) ve kaynaklar açısından (CPU, G/Ç, bellek) en az maliyetli olanı seçer.
3. Yürütücü (Executor) — sistemin "elleri". Hazır planı alır ve fiziksel olarak işlemleri gerçekleştirir: diskten sayfaları okur, satırları filtreler, sonuçları sıralar ve istemciye döndürür.

Bu bileşenler tampon yöneticisi (RAM'deki önbelleği yönetir) ve işlem yöneticisi (kilitleme mekanizmaları ve MVCC aracılığıyla veri bütünlüğünü sağlar) ile sıkı bir şekilde bağlantılıdır.

SQL sorgusunun 4 yaşam evresi

Herhangi bir sorgunun işleme süreci dört ardışık aşamaya bölünebilir.

1. Ayrıştırma ve anlamsal analiz

Bu aşamada, sorgu metni bir sözdizim ağacına (Parse Tree) dönüştürülür. DBMS şunları kontrol eder:

• Sözdizimi doğruluğu (eksik virgül veya tırnak işareti var mı?).
• Nesnelerin varlığı (orders tablosu şemada gerçekten var mı?).
• Erişim hakları (geçerli kullanıcı bu tabloyu okuyabilir mi?).
• Veri türlerinin uyumluluğu (tarih ile metin açıkça dönüştürülmeden karşılaştırılamaz).

Kontrol başarılı olursa, mantıksal sorgu planı oluşturulur; bu, nasıl yapılacağı değil, ne yapılması gerektiğine dair soyut bir açıklamadır.

2. Optimizasyon ve plan oluşturma

Bu, DBMS'nin kendisi için en yoğun kaynak tüketen aşamadır. İyileştirici, mantıksal planı fiziksel plana dönüştürür. İlişkisel cebir kurallarını ve sezgisel yöntemleri uygular:

• Predikatların aşağı itilmesi (Push-down): Veri filtreleme (WHERE) mümkün olduğunca erken yapılır, böylece sonraki işlemler için veri hacmi azaltılır.
• Birleştirme algoritmalarının seçimi: JOIN için tabloların boyutuna bağlı olarak yöntemlerden biri (Nested Loop, Hash Join, Merge Join) seçilir.
• Maliyet tahmini: Veri dağılımı histogramları gibi istatistiklere dayanarak, her alternatifin tahmini yürütme süresi hesaplanır.

İyileştiricinin sonucu, yürütücü için bir talimat olan yürütme planıdır (Execution Plan).

3. Fiziksel yürütme

Yürütücü plana göre çalışmaya başlar. Veri depolama yöneticisi ile etkileşime girer:

• Tampon önbelleğinden gerekli veri sayfalarını ister. Eğer orada yoksa (cache miss), diskten okuma başlatılır (G/Ç işlemi).
• Operatörleri uygular: indeks taraması, satır filtreleme, toplama (SUM, COUNT), sıralama.
• Kilitlemeleri yönetir: sorgu verileri değiştiriyorsa (UPDATE, INSERT), işlem çakışmalarını önlemek için kilitler kurulur.

4. Sonucun döndürülmesi

Oluşturulan veri kümesi istemci uygulamasına iletilir. Modern DBMS'lerde bu genellikle akış bazlı (cursor-based) gerçekleşir, böylece milyonlarca satır getirilirken sunucu belleği fazla meşgul edilmez.

İyileştirici en iyi planı nasıl seçer?

İyileştiricinin ana aracı istatistiklerdir. DBMS tablolar hakkında meta verileri saklar:

• Satır sayısı (kardinalite).
• Sütunlardaki benzersiz değerlerin sayısı.
• Veri dağılımı (histogramlar).

Bu verilere dayanarak, indeksin kullanılıp kullanılmayacağına karar verilir.

Yaygın hatalar ve optimizasyon yöntemleri

Mükemmel kod bile, veritabanı işlemcisinin çalışma mantığının yanlış anlaşılması nedeniyle yavaşlayabilir. İşte yaygın sorunlar ve çözümler.

Sorun 1: WHERE koşullarında fonksiyon kullanımı

WHERE YEAR(created_at) = 2025 şeklindeki bir sorgu, veritabanının her satıra fonksiyon uygulaması gerektiği için created_at sütunu üzerindeki normal indeksin kullanımını imkansız kılar. Çözüm: Aralık koşullarını kullanın: WHERE created_at >= '2025-01-01' AND created_at < '2026-01-01'. Bu, Index Range Scan kullanımına olanak tanır.

Sorun 2: SELECT'te gereksiz veriler

SELECT * kullanımı, veritabanını yalnızca iki sütun gerekse bile tüm sütunları okumaya zorlar. İndeks yalnızca gerekli sütunları kapsıyorsa, DBMS yine de diğer veriler için ana tabloya (Heap/Table Lookup) gider. Çözüm: Yalnızca gerekli sütunları seçin. İdeal olarak, SELECT ve WHERE içindeki tüm alanları içeren kapsayan indeksler (Covering Indexes) oluşturun.

Sorun 3: Dolaylı tür dönüşümü

Sütun VARCHAR türündeyse ve siz WHERE phone = 12345 şeklinde bir sayı gönderirseniz, veritabanı değer yerine sütun türünü dönüştürebilir, bu da indeks kullanımını devre dışı bırakır. Çözüm: Parametreleri her zaman kesinlikle ilgili veri türünde gönderin.

Sorun 4: Karmaşık görünümler (Views) ve ORM

ORM çerçeveleri genellikle gereksiz sorgular oluşturur veya INNER JOIN'in yeterli olduğu yerlerde LEFT JOIN kullanır. Görünümler verimsiz planları gizleyebilir. Çözüm: Veritabanına giden gerçek SQL kodunu her zaman kontrol edin ve EXPLAIN ANALYZE aracılığıyla analiz edin.

Sık sorulan sorular (SSS)

EXPLAIN ile EXPLAIN ANALYZE arasındaki fark nedir? EXPLAIN, istatistiklere dayalı olarak tahmini yürütme planını gösterir (teori). EXPLAIN ANALYZE sorguyu gerçekten yürütür ve gerçek süreyi ve satır sayısını gösterir (pratik). Hata ayıklama için her zaman ANALYZE kullanın.

Basit bir sorgu neden bazen uzun sürer? Nedenler harici olabilir: diğer işlemlerin kilitlemeleri (waiting on lock), diskte yüksek yük (I/O wait), sıralama için yetersiz RAM (spilling to disk) veya eski istatistikler.

Her zaman indeks oluşturmak gerekir mi? Hayır. Her indeks, veritabanının indeks yapısını güncellemesi gerektiği için yazma işlemlerini (INSERT, UPDATE, DELETE) yavaşlatır. İndeksler yalnızca belirli sık okuma sorguları için oluşturulmalıdır.

"Sıralı tarama" (Seq Scan) nedir ve bu kötü bir şey midir? Her zaman değil. Küçük tablolar için veya verilerin büyük bir kısmı seçildiğinde, Seq Scan indeks aramasından daha etkilidir çünkü diskten veri okuma büyük sürekli bloklar halinde gerçekleşir, bu da rastgele erişimlerden daha hızlıdır.