Yavaş SQL Sorguları Nasıl Hızlandırılır? Ölçmeden İyileştirmeye Adım Adım
Beceri rehberi

Yavaş SQL Sorguları Nasıl Hızlandırılır? Ölçmeden İyileştirmeye Adım Adım

Hazırlayan: Mindset Institute EditörlüğüGüncellendi: 4 dk okuma

Yavaş SQL sorguları nasıl tespit edilir, sorgu planı nasıl okunur, indeks ve birleştirme nasıl optimize edilir: adım adım performans ayarı rehberi.

Önce ölç: yavaş sorgu nasıl tespit edilir?

Optimizasyonun ilk kuralı tahmin etmemek, ölçmektir. Hangi sorgunun yavaş olduğunu sezgiyle değil, veritabanının sağladığı araçlarla belirleyin: yavaş sorgu günlüğü, sorgu istatistik görünümleri ve uygulama tarafı izleme. Tek bir sorgunun yavaşlığı kadar, çok sık çalışan orta hızdaki bir sorgunun toplam yükü de önemlidir.

Adayları iki ölçüte göre sıralayın: toplam harcadığı süre ve çalışma sıklığı. Sonra iyileştirmek istediğiniz sorgunun başlangıç süresini kaydedin. Gerçek veri hacmine yakın bir ortamda ölçün; küçük bir test tablosunda hızlı çalışan sorgu üretimde çok farklı davranabilir.

Ölçüm sırasında ön bellek etkisine dikkat edin: aynı sorguyu art arda çalıştırınca ikinci çalıştırma veriler bellekte olduğu için daha hızlı görünebilir. Karşılaştırmayı adil yapmak için aynı koşullarda birkaç kez ölçüp tutarlı bir değer kullanın.

Sorgu planı nasıl okunur?

Sorgu planı, veritabanının sorguyu nasıl çalıştıracağını gösteren adım listesidir. Çoğu veritabanında bir açıklama komutuyla alınır; gerçek çalışma süresi ve işlenen satır sayısını da gösteren sürümü, tahminle gerçeği karşılaştırmanızı sağlar.

Planda şunlara bakın: • Büyük bir tabloda tam tablo taraması var mı? • Veritabanının tahmin ettiği satır sayısı ile gerçekte işlenen satır sayısı arasında büyük fark var mı? Fark, eski istatistiklere işaret eder. • Birleştirme yöntemi seçilen veri hacmine uygun mu? • Sıralama veya gruplama diske taşıyor mu?

En maliyetli adımı bulup oradan başlayın. Her veritabanı sisteminin plan çıktısı ve terimleri farklıdır; kullandığınız sistemin belgelerini referans alın.

İndeks stratejisi

İndeks, veriye hızlı erişim için ek bir yapıdır; okumayı hızlandırır, yazmayı yavaşlatır ve yer kaplar. Bu yüzden her sütuna indeks atmak yerine, gerçek sorgulara göre seçici davranın.

İndeks adayları; filtrelerde (WHERE), birleştirmelerde (JOIN) ve sıralamada (ORDER BY) sık kullanılan sütunlardır. Birden çok sütun birlikte filtreleniyorsa bileşik indeks düşünün; burada sütun sırası önemlidir, çünkü indeks soldan sağa kullanılır. Bir sütuna fonksiyon uygulamak ya da değeri farklı veri tipine dönüştürmek çoğu zaman indeksin kullanılmasını engeller; filtreyi sütunu değiştirmeden yazmaya çalışın. Kullanılmayan ve mükerrer indeksleri belirli aralıklarla temizleyin.

Birleştirme ve toplama optimizasyonu

Birleştirmelerde ilk adım, birleştirilmeden önce satır sayısını azaltmaktır: filtreleri mümkün olduğunca erken uygulayın ve yalnızca ihtiyacınız olan sütunları seçin. Tüm sütunları getiren geniş bir seçim, gereksiz veri taşıma maliyeti yaratır.

Birleştirme sütunlarının her iki tarafta da indeksli ve aynı veri tipinde olması gerekir. İç içe alt sorgular bazen daha açık bir birleştirme ya da geçici bir ara tablo ile hem okunur hem hızlı hale gelir. Toplamalarda gruplanacak veri hacmini küçültmek için önce filtrelemek, mümkünse ön toplanmış (özet) tablolar kullanmak etkili olur. Her değişiklikten sonra planı yeniden alıp gerçekten iyileşme olup olmadığını doğrulayın.

Örnek bir iyileştirme akışı: bir sipariş raporu sorgusu üç tabloyu birleştirip tüm sütunları getiriyor olsun. Önce planı alın ve en maliyetli adımı bulun; çoğu zaman büyük tabloda tam tarama çıkar. Ardından tarih filtresini birleştirmeden önce uygulayın, yalnızca rapordaki sütunları seçin ve birleştirme sütunlarındaki indeksleri kontrol edin. Her adımdan sonra planı ve süreyi yeniden kaydedin. Hangi değişikliğin gerçekten fark yarattığını böyle görürsünüz; birden fazla değişikliği aynı anda yapmak neyin işe yaradığını gizler.

Eşzamanlılık, kilitler ve bağlantı etkileri

Bir sorgu yalnız başına hızlı olup canlı sistemde yavaşlayabilir; sebebi çoğunlukla eşzamanlılıktır. Uzun süren bir işlem satırları kilitlediğinde, diğer işlemler beklemek zorunda kalır. İşlemleri kısa tutun, gereksiz yere açık bırakmayın ve tablolara tutarlı bir sırayla erişin; böylece kilit kilitlenmesi (deadlock) riski azalır.

Bağlantı sayısı da performansı belirler. Her bağlantı kaynak tüketir; çok sayıda eşzamanlı bağlantı veritabanını yorabilir. Uygulama tarafında bağlantı havuzu kullanmak ve havuz boyutunu veritabanı kapasitesine göre ayarlamak bu etkiyi azaltır. Bekleme olaylarını izlemek, yavaşlamanın hesaplamadan mı yoksa beklemeden mi kaynaklandığını gösterir.

Kalıcı iyileştirme ve sık yapılan hatalar

İyileştirmenin kalıcı olması için sonuçları kayıt altına alın: önceki ve sonraki süre, değişiklik, nedeni. Önemli sorgular için otomatik performans testi ya da izleme eşiği koyarak ileride bir kod ya da veri değişikliği sorguyu yeniden yavaşlattığında hemen fark edin.

Sık hatalar: • Ölçmeden tahminle indeks eklemek. • Tüm sütunları seçmek (SELECT *) ve gereksiz veri taşımak. • Eski istatistikler yüzünden veritabanının yanlış plan seçmesini göz ardı etmek. • Fonksiyonla sarılmış sütun üzerinde filtre yazarak indeksi devre dışı bırakmak. • Optimizasyonu yalnızca sorguda aramak; bazen çözüm veri modelinde ya da uygulamadaki gereksiz sorgu tekrarındadır.

Mindset programlarında bu beceriyi nerede çalışırsınız?

Mindset kataloğundaki SQL Performans Ayarı ve Sorgu Optimizasyonu eğitimi şu modüllerle ilerler: Performans Ölçümü ve Yavaş Sorgu Tespiti, Sorgu Planı Analizi, İndeks Stratejisi, Birleştirme ve Toplama Optimizasyonu, Eşzamanlılık, Kilit ve Bağlantı Etkileri, Kalıcılık, Regresyon Koruması ve Raporlama.

Modül sırası bu sayfadaki akışı izler: önce ölçüm ve plan okuma, sonra indeks ile birleştirme düzenlemeleri, en sonda canlı sistem etkileri ve kalıcı koruma.

İlgili Mindset programı

SQL Performans Ayarı ve Sorgu Optimizasyonu

Sık sorulanlar

Sık sorulan sorular

Sorgu optimizasyonuna nereden başlamalıyım?

Önce yavaş ve çok çalışan sorguları ölçerek belirleyin, sonra en maliyetli olanın sorgu planını inceleyin. Genellikle bir tam tablo taraması, eksik indeks ya da gereksiz veri taşıma bulunur. Tek değişiklik yapıp yeniden ölçün.

Daha fazla indeks her zaman daha hızlı demek midir?

Hayır. İndeksler okumayı hızlandırır ama her yazma işleminde güncellenmek zorunda olduğundan yazmayı yavaşlatır ve depolama kullanır. Yalnızca gerçek sorgulara hizmet eden indeksleri tutmak daha sağlıklıdır. Örneğin yalnızca nadir çalışan bir rapor için eklenen indeks, her gün çok sayıda yazma yapan bir tabloda kazançtan çok yük getirebilir; bu yüzden indeksin hangi sorguya hizmet ettiğini not etmek iyi bir alışkanlıktır.

Bu bilgiler tüm veritabanları için geçerli mi?

Temel ilkeler, yani ölçme, plan okuma, indeks ve birleştirme mantığı, çoğu ilişkisel veritabanı için ortaktır. Ancak plan komutları, istatistik yönetimi ve izleme araçları sisteme göre değişir; ayrıntılar için kullandığınız ürünün belgelerine bakın.

Veritabanı yöneticisi olmadan da SQL optimize edebilir miyim?

Evet. Analist ya da geliştirici olarak kendi sorgularınızı ölçebilir, planlarını okuyabilir ve yeniden yazabilirsiniz. Sunucu ayarı ya da indeks değişikliği gibi işlemler için veritabanı yöneticisiyle birlikte çalışmak gerekir. Önce kendi sorgunuzun planını alıp tam tablo taraması, gereksiz sütun seçimi ve filtredeki fonksiyon kullanımı gibi sorgu düzeyindeki kusurları giderin; çoğu kazanım zaten burada çıkar.

SQL Sorgu Optimizasyonu Nasıl Yapılır? Performans Ayarı