Bir Satır SQL, 150 Kat Hız: Index'in Gücü

20 yıl önce bir MySQL tablosu bana veritabanlarının en değerli dersini öğretti.

2004 civarı. Elimde 5 milyon kayıtlık bir MySQL tablosu var. Basit bir sorgu yazıyorum:

SELECT * FROM orders WHERE customer_id = 12345;

Enter'a basıyorum. Bekliyorum. Bekliyorum. 30 saniye sonra sonuç geliyor.

"Sunucu yavaş" diye düşündüm. Daha güçlü donanım lazım. Belki RAM yetersiz. Belki disk eski.

Yanılıyordum.

Kütüphaneci Analojisi

Düşünün: Bir kütüphaneye girdiniz. 5 milyon kitap var. "Müşteri No: 12345" etiketli kitabı arıyorsunuz.

Senaryo A: Kütüphaneci ilk raftan başlayıp her kitabı tek tek kontrol ediyor. "Bu mu? Bu mu? Bu mu?" 5 milyon kez.

Senaryo B: Kütüphaneci kataloğa bakıyor. "Müşteri No: 12345... Raf 7, Sıra 3, Kitap 42." Direkt gidiyor, alıyor, getiriyor.

Index olmayan bir veritabanı sorgusu Senaryo A'dır. Full table scan. Her satırı tek tek okur, karşılaştırır, uymayanları atar.

Index olan bir sorgu Senaryo B'dir. Katalog (index) size tam olarak nereye bakacağınızı söyler.

O Gün Ne Oldu?

Araştırmaya başladım. "MySQL slow query" diye aratıyorum. Karşıma "index" kavramı çıkıyor. Şüpheyle yaklaşıyorum—bu kadar basit olamaz.

Deniyorum:

CREATE INDEX idx_customer ON orders(customer_id);

Birkaç dakika bekledim (5 milyon kayıt için index oluşturmak zaman alıyor). Sonra aynı sorguyu tekrar çalıştırdım:

SELECT * FROM orders WHERE customer_id = 12345;

0.2 saniye.

Ekrana baktım. Tekrar çalıştırdım. Yine 0.2 saniye.

30 saniyeden 0.2 saniyeye. 150 kat iyileşme. Donanım aynı. Veri aynı. Sadece bir satır SQL.

O gün veritabanlarına bakış açım tamamen değişti.

Index Nasıl Çalışır?

Teknik detaya çok girmeden, temel mantık şu:

Index olmadan: Veritabanı tüm tabloyu baştan sona tarar. 5 milyon satır = 5 milyon karşılaştırma.

Index ile: Veritabanı bir B-tree (veya benzeri) yapısı kullanır. Bu yapı, aradığınız değere logaritmik zamanda ulaşmanızı sağlar. 5 milyon satır ≈ 23 karşılaştırma.

Matematiksel olarak:

• Full scan: O(n) = 5.000.000 işlem
• Index scan: O(log n) ≈ 23 işlem

23 işlem mi, 5 milyon işlem mi? Fark burada.

Hangi Sütunlara Index?

Her sütuna index koymak çözüm değil. Index'in kendisi de yer kaplar ve yazma işlemlerini yavaşlatır (her INSERT/UPDATE'te index de güncellenmeli).

Temel kural:

Index koy:

• WHERE clause'da sık kullandığın sütunlar
• JOIN koşullarında kullanılan sütunlar
• ORDER BY ile sıraladığın sütunlar
• Foreign key'ler

Index koyma:

• Nadiren sorgulanan sütunlar
• Çok az unique değer içeren sütunlar (örn: boolean)
• Sürekli güncellenen sütunlar

Composite Index: Sıra Önemli

Birden fazla sütunu birlikte indexleyebilirsiniz:

CREATE INDEX idx_customer_date ON orders(customer_id, order_date);

Bu index şu sorguları hızlandırır:

• WHERE customer_id = 123
• WHERE customer_id = 123 AND order_date > '2024-01-01'

Ama şunu hızlandırmaz:

• WHERE order_date > '2024-01-01'

Neden? Çünkü composite index soldan sağa çalışır. Telefon rehberi gibi düşünün: Önce soyadı, sonra isim. Soyadını bilmeden isme göre arayamazsınız.

EXPLAIN: Sorgunuzun Röntgeni

Bir sorgunun index kullanıp kullanmadığını nasıl anlarsınız?

EXPLAIN SELECT * FROM orders WHERE customer_id = 12345;

Çıktıda şunlara bakın:

type: ALL görüyorsanız, sorgunuz tüm tabloyu tarıyor demektir. Alarm zili.

Her Veritabanında Aynı Mantık

20 yılda MySQL, PostgreSQL, SQL Server, Oracle, hatta MongoDB ile çalıştım. Index mantığı hepsinde aynı:

• MySQL: CREATE INDEX, EXPLAIN
• PostgreSQL: CREATE INDEX, EXPLAIN ANALYZE
• SQL Server: CREATE INDEX, Execution Plan
• MongoDB: createIndex(), explain()

Sözdizimi değişir, konsept aynı kalır. Bir veritabanında öğrendiğiniz, diğerlerinde de geçerli.

AI Çağında Index

Bugün bir sorgunun neden yavaş olduğunu anlamak için günlerce araştırmanıza gerek yok. Claude'a veya benzeri bir AI aracına sorgunuzu ve tablo yapınızı verip "Bu neden yavaş?" diye sorabilirsiniz.

"Şu sorgum 30 saniye sürüyor:
SELECT * FROM orders WHERE customer_id = 12345;

Tablomda 5 milyon kayıt var. Ne yapmalıyım?"

Cevap saniyeler içinde gelir. Index önerisi, EXPLAIN çıktısı yorumu, hatta sorgu optimizasyonu.

20 yıl önce bu bilgiye ulaşmak için forumları, man page'leri, kalın kitapları taramam gerekiyordu. Şimdi bir sohbet kadar kolay.

Ama—ve bu önemli—AI'ın verdiği cevabı anlamak hâlâ size kalmış. Index'in ne olduğunu, neden çalıştığını bilmezseniz, AI'ın önerisini körü körüne uygularsınız. Çalışır, ama neden çalıştığını bilemezsiniz. Bir sonraki sorunda yine çaresizsiniz.

Pratik Kontrol Listesi

Veritabanınız yavaşlıyorsa, şu adımları izleyin:

1. Yavaş sorguları tespit edin

-- MySQL
SET GLOBAL slow_query_log = 'ON';
SET GLOBAL long_query_time = 1; -- 1 saniyeden uzun sorgular

2. EXPLAIN ile analiz edin

EXPLAIN SELECT ...;

3. Eksik index'leri belirleyin

• type: ALL olan sorgular
• WHERE/JOIN sütunları index'li mi?

4. Index ekleyin, test edin

CREATE INDEX idx_name ON table(column);

5. Ölçün

• Önce: X saniye
• Sonra: Y saniye
• İyileşme: X/Y kat

Sonuç

30 saniyeden 0.2 saniyeye geçiş, kariyerimin dönüm noktalarından biriydi. Donanıma para harcamadan, koda dokunmadan, tek bir SQL satırıyla 150 kat performans artışı.

Index bir kabus değil. Kütüphanedeki katalog sistemi kadar mantıklı, bir kez öğrenildiğinde unutulmayan bir pratik.

Ve güzel haber: Artık öğrenmek hiç bu kadar kolay olmamıştı. AI araçları, her sorgunuzda yanınızda bir veritabanı uzmanı gibi.

Tek yapmanız gereken sormak.

Cem Karaca, VeriTeknik

Dipnot: Bu yazıdaki 5 milyon kayıt örneği 2004'ten. Bugün milyar kayıtlık tablolar bile yaygın. Ama temel prensip aynı: Index olmadan, en güçlü sunucu bile diz çöker. Index ile, mütevazı donanım bile mucizeler yaratır.