SQL query tuning ile ne kadar hızlanma elde edilir?

Kazanım sorunun türüne bağlıdır. Eksik index eklenmesi tipik olarak %70-%98 arası hızlanma getirir; join sırası veya algoritma değişikliği %40-%75, istatistik güncellemesi %30-%85, parametre sniffing düzeltmesi %50-%90 kazanım sağlar. 12 dakikadan 4 saniyeye inen raporlar saha vakalarında olağandır.

Sorgu yavaşlığının ilk olarak nereden anlaşılması gerekir?

Execution plan'da Actual ile Estimated satır sayıları arasındaki farktan başlanır. Bu fark büyükse istatistik bayatlamıştır. Ardından Key Lookup, Hash Match warning, Sort operatörü ve implicit conversion gibi pahalı operatörler işaretlenir. Çoğu yavaşlığın kök nedeni bu kontrol listesinden çıkar.

Her yavaş sorgu için yeni index açmak doğru mu?

Hayır. Her index INSERT, UPDATE ve DELETE maliyetini artırır, disk yeri ve bakım yükü getirir. Önce sys.dm_db_index_usage_stats ile mevcut index'lerin kullanım oranı bakılır. Birden fazla benzer index varsa birleştirilir. Yeni açılacak index'te eşik kolonları, INCLUDE listesi ve sıralama dikkatli tasarlanır.

Aynı sorgu bazen hızlı bazen yavaş çalışıyor, sebebi ne olabilir?

Genellikle parametre sniffing problemidir. Optimizer ilk çalıştırılan parametre değeri için plan üretir ve cache'ler; sonraki çağrılar bu plana uymazsa yavaşlar. Çözüm olarak OPTION (RECOMPILE), OPTIMIZE FOR, OPTIMIZE FOR UNKNOWN veya plan guide kullanılabilir. Kullanım profiline göre doğru çözüm seçilir.

Query tuning ile mimari değişiklik arasındaki sınır nedir?

Bir sorgu zaten optimal plan kullanıyor, indeksleri doğru ve istatistikleri güncelse tuning sınırına gelinmiştir. Bu noktadan sonra partitioning, indexed view, columnstore index, denormalize raporlama tablosu veya OLTP ile analitik yükün ayrılması gibi mimari kararlar gerekir. Tuning her yavaşlığın cevabı değildir.

Tuning sırasında değişikliklerin etkisi nasıl doğrulanır?

Baseline alınır: süre, CPU, I/O ve plan kaydedilir. Aynı anda yalnızca tek değişiklik yapılır (index, hint veya yeniden yazım). Cache temizlenip aynı parametre setiyle yeniden ölçülür. Ardından regresyon kontrolü yapılır: başka sorguların yavaşlayıp yavaşlamadığına bakılır. Bu döngü dışında yapılan iyileştirmeler kanıtsız kalır.

Query tuning hangi veritabanı motorlarında uygulanır?

Disiplin motor bağımsızdır. SQL Server, Oracle, PostgreSQL, MySQL ve MariaDB'nin tamamında execution plan analizi, index stratejisi, istatistik yönetimi ve sorgu yeniden yazımı geçerlidir. Sadece araç isimleri (EXPLAIN, SET STATISTICS, AUTOTRACE) ve plan operatörlerinin görüntüleniş biçimi farklıdır; mantık aynıdır.

Tuning iş sonuçlarına nasıl yansır?

Sadece teknik bir kazanım değildir. Ay sonu finans raporunun 12 dakikadan 4 saniyeye inmesi kapanış süresini kısaltır, e-ticaret arama sorgusunun 200 ms'ye inmesi dönüşüm oranını yükseltir, gece ETL'in 6 saatten 40 dakikaya inmesi bakım penceresi açar. Çoğu vakada donanım yatırımının önüne geçer.

SQL QUERY TUNING NEDİR?

SQL execution plan ağacında join ve scan operatörlerinin maliyet işaretleriyle hiyerarşik gösterimi

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ı.

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.

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.

Bir Sorgunun Yavaşlık Sebebini Bulmak

Tuning öncesi ve sonrası sorgu süresinin uzun ve kısa çubuklarla karşılaştırıldığı kazanım grafiği

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

Actual vs Estimated rows farkı: Optimizer 100 satır bekliyor ama 4 milyon satır geliyorsa istatistik bayatlamış demektir.
Key Lookup / RID Lookup: Index seek sonrası tabloya geri dönüş varsa covering index düşünülmelidir.
Hash Match (warning sembolü): tempdb'ye spill ediyor olabilir, bellek tahmini düşük kalmıştır.
Sort operatörü: Index sırasıyla çakışmayan ORDER BY pahalıya patlar.
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.

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.

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.

Tuning Sürecini Sistematik Yürütmek

Query tuning döngüsünün baseline ölçüm değişiklik ve regresyon kontrol adımlarını içeren akış şeması

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.

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.