SQL Sorgu Optimizasyonu: İndeks, JOIN ve Sorgu Planı Analizi

Veritabanı sorgu performansı, uygulama yanıt sürelerini, altyapı maliyetlerini ve kullanıcı deneyimini doğrudan etkiler. Basit değişikliklerle önemli kazançlar sağlanabilir: doğru indeks seçimi, JOIN yapılarının düzenlenmesi ve sorgu planı analizi ile dar boğazlar tespit edilip giderilebilir. Aşağıdaki rehber pratik adımlar, örnekler ve kontrol listeleri sunar.

Temel kavramlar: Neden odaklanmalısınız?

İyi bir sorgu optimizasyonu süreci şu üç bileşene dayanır: indeksler (veriye hızlı erişim sağlar), JOIN optimizasyonu (satır sayısını azaltmak ve uygun algoritmaları kullanmak) ve sorgu planı analizi (sorgunun nasıl yürütüldüğünü görmek). Bu yaklaşımlar, uygulamanızın okuma/yazma profilini ve veri büyümesini göz önünde bulundurarak uygulanmalıdır. Genel ilkeler ve pratik örnekler için kaynak rehberleri inceleyebilirsiniz: Semih Bebek ve Novatorsoft.

İndeksler: Ne zaman, nasıl ve hangi sütunlara?

İndeksler tablodaki verilere daha hızlı erişim sağlar; ancak her indeksin bir maliyeti vardır (disk alanı ve yazma zamanı). İndeks oluştururken dikkat edilmesi gereken temel noktalar:

• Seçicilik (cardinality): Çok çeşitli değerlere sahip sütunlar genellikle indeks için daha faydalıdır. Düşük seçiciliğe sahip sütunlarda (ör. boolean) indeks fayda sağlamayabilir.
• Tek sütunlu vs bileşik indeks: Sorgularınız genellikle tek sütunla filtreliyorsa tek sütunlu indeks uygundur. Birden fazla sütun içeren sık kullanılan filtre veya sıralama kombinasyonları için bileşik (composite) indeks tercih edin. Örnek: CREATE INDEX idx_orders_userid_date ON orders(user_id, created_at);
• Örtüleyen (covering) indeks: Sorgunun ihtiyaç duyduğu tüm sütunları içeren bir indeks, veritabanının tabloya erişmesi gerekmeden sorguyu karşılamasını sağlar.
• Yazma yükü ve indeks sayısı: Her yeni indeks yazma ve güncelleme maliyetini artırır. Sık güncellenen tablolarda gereksiz indekslerden kaçının.

İndeksleme stratejileriyla ilgili pratik kurallar ve örnek yaklaşımlar için bakınız: EkaSunucu ve ilgili rehberler.

İndeks oluşturma örnekleri

Basit bir örnek: e-posta sütunu için tek sütunlu indeks:

CREATE INDEX idx_users_email ON users(email);

Bileşik indeks örneği (sık kullanılan filtre+sort kombinasyonu):

CREATE INDEX idx_orders_userid_date ON orders(user_id, created_at);

JOIN optimizasyonu: Satır sayısını azalt, doğru sütunları bağla

JOIN işlemleri genellikle sorgu maliyetini yükselten noktalardır. Aşağıdaki uygulamalar performansı iyileştirmeye yardımcı olur:

• Erken filtreleme: JOIN işleminden önce mümkün olduğunca WHERE şartı veya ara sorgu ile satır sayısını azaltın. Böylece JOIN sırasında işlenecek veri miktarı düşer.
• İndeksli bağlantı sütunları: JOIN koşulunda kullandığınız sütunların indeksli olması hem nested loop hem de hash join performansını olumlu etkiler.
• Doğru JOIN türünü seçin: INNER JOIN çoğunlukla daha hızlıdır çünkü eşleşmeyen satırları dışlar. LEFT/RIGHT JOIN gerektiğinde kullanın; gereksiz dış JOIN'lerden kaçının.
• SELECT * kullanmaktan kaçının: Yalnızca ihtiyaç duyulan sütunları seçmek I/O ve hafıza tüketimini azaltır.

Örnek: Kullanıcı ve sipariş tablolarını bağlarken önce siparişleri filtreleyip sonra kullanıcı ile birleştirmek daha etkin olabilir:

SELECT u.id, u.name, o.total FROM users u JOIN (SELECT user_id, total FROM orders WHERE created_at > '2024-01-01') o ON u.id = o.user_id;

Bu tür yaklaşımlar ve JOIN davranışları hakkında daha fazla bilgi için kaynakları inceleyin: Semih Bebek.

Sorgu Planı Analizi: EXPLAIN ve yorumlama

Sorgu planı, veritabanı motorunun sorgunuzu nasıl yürüteceğini gösterir. Çoğu sistemde EXPLAIN komutu tahmini yürütme planını verir; bazı sistemlerde (ör. PostgreSQL) EXPLAIN ANALYZE sorguyu gerçekten çalıştırıp gerçek maliyet ve süreyi gösterir. Sorgu planı okumaya yönelik dikkat edilmesi gerekenler:

• Full table scan (seq scan / full scan): Tablo baştan sona taranıyorsa ve tablo büyükse, bir indeks kullanımı düşünülebilir.
• Index scan vs index seek: İndeks taraması genelde daha az maliyetlidir; hangi indeksten nasıl yararlanıldığını görün.
• Join algoritmaları: Plan içinde nested loop, hash join veya merge join görülebilir. Hangi algoritmanın seçildiği sorgu ve veri dağılımına bağlıdır—büyük tablolar arasında nested loop maliyetli olabilir.
• Maliyet ve tahminler: Planın gösterdiği tahmini satır sayıları ve maliyet değerleri, optimizasyonun odak noktalarını gösterir. Tahminler gerçek koşullara göre sapma gösterebilir; bu nedenle gerçek yürütme ölçümleriyle karşılaştırın.

EXPLAIN çıktısını yorumlama ve örnekler için rehbere bakabilirsiniz: Novatorsoft.

Pratik adımlar: Adım adım optimizasyon akışı

1. Baseline oluşturun: Önce sorgunun mevcut yürütme süresini, CPU ve I/O istatistiklerini kaydedin (staging veya production izleme verilerinden).
2. Yavaş sorguları tespit edin: Slow query log, APM veya veritabanı izleme araçlarıyla en maliyetli sorguları listeleyin.
3. EXPLAIN ile planı alın: Sorgunun tahmini/gerçek planını inceleyin; full scan, büyük nested loop veya temp file kullanımı varsa not edin.
4. İndeks ve veri tiplerini kontrol edin: JOIN ve WHERE sütunlarının indeksli olup olmadığını, sütun veri tiplerinin uyumlu olup olmadığını doğrulayın.
5. Değişiklikler yapın ve ölçün: Yeni indeks, sorgu yeniden yazımı veya istatistik güncellemesi gibi adımları uygulayın; her adımı teker teker ölçün.
6. Regresyon testleri: Yazma işlemleri üzerindeki etkisini kontrol edin; indekslerin yazma maliyetini gözlemleyin.
7. Yayınlama: Başarılı değişiklikleri planlı pencerelerde üretime alın ve izlemeye devam edin.

Kontrol listesi: Hızlı doğrulamalar

• SELECT * kullanmıyor musunuz?
• JOIN ve WHERE sütunları indeksli mi?
• Bileşik indeksler sorgu sırasına göre mi oluşturuldu?
• Fonksiyon kullanımı WHERE/JOIN koşullarını bozuyor mu? (örn. WHERE LOWER(name) = 'ali')
• Tablo istatistikleri güncel mi?
• Yazma yoğun tablolar için indeks sayısı makul mü?
• EXPLAIN çıktısında büyük temp kullanımı veya full scan var mı?

Sık yapılan tuzaklar

En yaygın hatalar şunlardır: gereksiz indeks oluşturmak, WHERE/JOIN koşullarında fonksiyon kullanmak (indeks kullanımını engelleyebilir), SELECT * kullanmak ve sorguyu ölçmeden değişiklik yapmak. Her değişikliğin etkisini ölçmek için aşamalı test ve geri alma stratejisi uygulayın.

Sonuç

İyi planlanmış indeksler, dikkatli JOIN yapıları ve düzenli sorgu planı analizi ile veritabanı performansını önemli ölçüde iyileştirebilirsiniz. Değişiklikleri önce test ortamında denemek, her adımı ölçmek ve DBMS'e özgü dokümantasyonu takip etmek en sağlıklı yaklaşımdır. Daha fazla teknik örnek ve derinlemesine açıklama için şu kaynakları inceleyin: Semih Bebek, Novatorsoft ve EkaSunucu.

Not: Bu makaledeki örnekler genel amaçlıdır; kullanılan veritabanı yönetim sistemine göre komut ve davranış farklılık gösterebilir. Her zaman sistem belgelerini ve test sonuçlarını referans alın.