SQL Server'da Yavaş Sorgu: Nereden Başlamalı?

Uygulama yavaşladığında ilk suçlanan kod olur. Oysa çoğu zaman sorun veritabanındadır ve birkaç adımda bulunabilir.

"Sistem yavaşladı" şikâyeti geldiğinde sunucuya RAM eklemek en hızlı ama en pahalı çözümdür. Çoğu durumda asıl sorun tek bir sorgudadır ve yarım saatte bulunur.

Önce ölçün, sonra tahmin edin

Hangi sorgunun yavaş olduğunu bilmeden yapılan her iyileştirme tahmindir. Query Store veya sys.dm_exec_query_stats görünümü, toplam süreye en çok katkı yapan sorguları doğrudan gösterir.

Yürütme planına bakın

Planda Table Scan veya Index Scan görüyorsanız ve tablo büyükse, muhtemelen uygun bir indeks yok demektir. Key Lookup ise indeksin var ama eksik olduğunu, sorgunun ihtiyacı olan sütunların indekse dahil edilmediğini gösterir.

Sık karşılaşılan üç hata

• Sütun üzerinde fonksiyon. WHERE YEAR(Tarih) = 2025 yazıldığında indeks kullanılamaz. Aralık karşılaştırması yazmak sorguyu dramatik biçimde hızlandırır.
• Gereksiz SELECT *. İhtiyaç duyulmayan sütunlar hem ağ trafiğini hem de kapsayıcı indeks kullanma ihtimalini düşürür.
• Tip uyuşmazlığı. nvarchar bir sütunu varchar parametreyle karşılaştırmak örtük dönüşüme ve tam tablo taramasına yol açar.

Parametre sniffing

Aynı sorgunun bazen hızlı bazen yavaş çalışması tipik bir parametre sniffing belirtisidir. İlk çalıştırmada oluşan plan, sonraki farklı parametreler için uygun olmayabilir. OPTION (RECOMPILE) teşhis için iyi bir başlangıçtır, ancak kalıcı çözüm genelde sorguyu veya indeksi düzeltmektir.

İndeks eklemeden önce

Her yavaş sorgu için yeni indeks eklemek, yazma işlemlerini yavaşlatır. Önce mevcut indekslerin kullanım istatistiklerine bakın; çoğu zaman var olan bir indeksi genişletmek yenisini eklemekten daha iyidir.