SQL QUERY TUNING NEDİR?

Kurumsal raporlama ortamlarında yapılan ölçümler şunu söylüyor: tipik bir BI sorgusunda execution plan'ı doğru kurguladığınızda yanıt süresi %60 ile %95 arasında düşüyor; bazı vakalarda 12 dakikalık bir rapor 4 saniyeye iniyor. Aynı veritabanı, aynı donanım, aynı sorgu sonucu — değişen tek şey planın kendisi. SQL query tuning, işte tam olarak bu farkı yaratan disiplinin adı.

1. SQL Query Tuning Tam Olarak Nedir?

SQL query tuning, bir sorgunun ürettiği sonucu değiştirmeden çalışma süresini, CPU tüketimini, I/O maliyetini ve bellek kullanımını azaltma sürecidir. Sorguyu yeniden yazmak bunun bir parçasıdır ama tamamı değildir. Optimizer'ın seçtiği execution plan'ı analiz etmek, gerektiğinde index oluşturmak, istatistikleri güncel tutmak ve parametre duyarlılığı sorunlarını çözmek de aynı bütünün bileşenleridir. Konuya ilişkin proje sayfasını ek bir başvuru kaynağı olarak değerlendirilebilir.

Bir sorgu yavaş çalıştığında neden yavaş çalıştığını anlamak için önce planı okumanız gerekir. Plan, optimizer'ın hangi tabloya hangi sırayla eriştiğini, hangi join algoritmasını (Nested Loop, Hash Match, Merge) seçtiğini ve her adımda kaç satır beklediğini gösterir.

2. Execution Plan Değişikliğiyle Gelen Hız Kazanımları

Sahadan toplanan kazanım oranları kategoriye göre belirgin farklılıklar gösteriyor:

• Eksik index eklenmesi: Tablo taraması (Table Scan) yerine Index Seek geldiğinde tipik kazanım %70-%98 arasıdır. 50 milyon satırlık bir tabloda doğru bir composite index, 8 dakikalık sorguyu 0.3 saniyeye indirebilir.
• Join sırası ve algoritma değişikliği: Hash Match yerine doğru sırada Nested Loop seçimi orta ölçekli sorgularda %40-%75 hızlanma sağlar.
• İstatistik güncellemesi: Optimizer'ın cardinality tahmini düzeldiğinde aynı sorgu için %30-%85 arası iyileşme görülür.
• Parametre sniffing düzeltmesi: OPTION (RECOMPILE) veya OPTIMIZE FOR ile değişken kullanım senaryolarında %50-%90 kazanım tipiktir.
• Sorgu yeniden yazımı (subquery → JOIN, IN → EXISTS): Mantıksal denkliği koruyarak %25-%60 iyileşme.

Bu oranlar tek bir veritabanı motoruna özgü değildir. SQL Server, Oracle, PostgreSQL ve MySQL'de aynı disiplinler benzer büyüklükte sonuç verir; sadece araç isimleri ve plan operatörlerinin görüntülenme biçimi değişir.

3. Bir Sorgunun Yavaşlık Sebebini Bulmak

Tuning'in ilk kuralı: tahmin etmeyin, ölçün. Bir sorgu yavaşladığında bakılması gereken başlıca göstergeler şunlardır:

1. Actual vs Estimated rows farkı: Optimizer 100 satır bekliyor ama 4 milyon satır geliyorsa istatistik bayatlamış demektir.
2. Key Lookup / RID Lookup: Index seek sonrası tabloya geri dönüş varsa covering index düşünülmelidir.
3. Hash Match (warning sembolü): tempdb'ye spill ediyor olabilir, bellek tahmini düşük kalmıştır.
4. Sort operatörü: Index sırasıyla çakışmayan ORDER BY pahalıya patlar.
5. Implicit conversion: WHERE kolonu CAST'leniyorsa index kullanılmaz, sorgu tarama yapar.

Bu beş madde, yavaş sorguların büyük çoğunluğunda kök nedeni doğrudan açığa çıkarır. Geriye kalan kısım disiplinli ölçüm ve doğrulamadır.

4. Index Stratejisi: Az ve Doğru

Yaygın bir hata, her yavaş sorgu için yeni bir index açmaktır. Oysa her index, INSERT/UPDATE/DELETE maliyetini artırır ve disk yer tüketir. İyi bir tuning yaklaşımı; mevcut indexleri analiz eder, kullanılmayanları (sys.dm_db_index_usage_stats) tespit eder ve gerçekten gerekli olan composite index'leri eşik kolonları + INCLUDE listesi mantığıyla tasarlar.

5. Tuning'in İş Sonuçlarına Etkisi

Query tuning sadece teknik bir iyileştirme değildir. 12 dakikalık bir finans raporunun 4 saniyeye inmesi, ay sonu kapanış sürelerini kısaltır; e-ticaret arama sorgusunun 2 saniyeden 200 ms'ye inmesi dönüşüm oranını ölçülebilir biçimde yükseltir; gece çalışan ETL'in 6 saatten 40 dakikaya inmesi bakım pencerelerini serbest bırakır. Aynı donanımda elde edilen bu kazanım, çoğu zaman donanım yatırımının önüne geçer.

Konuyu uygulamalı senaryolar ve gerçek execution plan örnekleri üzerinden derinleştirmek isterseniz SQL Performance ve Query Tuning eğitimi içeriğinden yararlanabilirsiniz.

6. Tuning Sürecini Sistematik Yürütmek

Disiplinli bir tuning döngüsü dört adımdan oluşur: baseline al (mevcut süre, plan, I/O, CPU değerlerini kaydet), tek bir değişiklik yap (index, hint, yeniden yazım — aynı anda birden fazlasını değil), aynı koşullarda yeniden ölç (cache'i temizle, parametre setini değiştir) ve regresyon kontrolü yap (başka sorgular yavaşladı mı?). Bu döngü kısa tutulduğunda hangi değişikliğin etki yarattığı şüphesiz biçimde belirlenir.

7. Ne Zaman Tuning, Ne Zaman Mimari Değişiklik?

Her yavaşlık tuning ile çözülmez. Bir sorgu zaten optimal plan'ı kullanıyor ve hâlâ kabul edilemez sürede çalışıyorsa cevap farklı yerdedir: partitioning, materialized view / indexed view, kolon mağazası (columnstore) index, denormalize edilmiş raporlama tablosu veya OLTP ile analitik yükün ayrılması. Tuning'in sınırını bilmek, tuning yapabilmek kadar değerlidir; bu sınırın nasıl çizileceğini SQL Performance ve Query Tuning eğitimi içeriğinde inceleyebilirsiniz.

SQL query tuning'in özü tek cümleyle şudur: aynı sonucu üreten farklı yolların maliyeti çok farklıdır ve doğru yolu seçme işi optimizer'a bırakıldığında bazen yanılır. Bu yanılgıyı görmek, kanıtlamak ve düzeltmek tuning uzmanının yaptığı iştir.