SQL Server'da Key Lookup yüzünden yavaş sorguyu düzeltme
Execution plan'da Key Lookup (veya heap'lerde RID Lookup) operatörü görüyorsanız, SQL Server nonclustered index'te bulunmayan kolonları almak için her satırda clustered index'e geri gidiyor demektir. Yüksek satır sayısında bu dramatik yavaşlama yaratır.
Kendi sorgunuzu yapıştırın — bağlantı olmadan, saniyeler içinde teşhis alın.
Sorgu Analizcisini açBelirtiler
- Execution plan'da 'Key Lookup (Clustered)' operatörü ve ona giden Nested Loops
- Mantıksal okuma (logical reads) sayısının beklenenden çok yüksek olması
- İndex var ama sorgu hâlâ yavaş
Kök nedenler
- Nonclustered index SELECT/WHERE'deki tüm kolonları kapsamıyor (non-covering)
- Index seek doğru ama eksik kolonlar için lookup gerekiyor
Çözüm adımları
Eksik kolonları INCLUDE ile kapsa
WHERE/JOIN kolonlarını index anahtarında, SELECT'te dönen ek kolonları INCLUDE listesinde tutan bir covering index oluşturun. Böylece lookup tamamen ortadan kalkar.
Index'i doğrula
Yeni index sonrası execution plan'ı tekrar alın; Key Lookup'ın kaybolup yerini tek bir Index Seek'e bıraktığını teyit edin.
Aşırı index'ten kaçın
Çok geniş INCLUDE listeleri yazma maliyetini artırır. Yalnızca bu sorgunun gerçekten döndürdüğü kolonları ekleyin.
Sık sorulanlar
Key Lookup her zaman kötü müdür?
Hayır. Az sayıda satır döndüren sorgularda Key Lookup kabul edilebilir. Sorun, yüksek satır sayısında her satır için tekrarlandığında ortaya çıkar.
Covering index yerine clustered index'i mi değiştirmeliyim?
Genelde hayır. Clustered index değişikliği tüm tabloyu etkiler; hedefli bir covering nonclustered index daha güvenli ve odaklıdır.
Sorgunuzu ChatGPT'ye değil, senior DBA'ye sorun
Deterministik DBA checklist + execution plan analizi. Bağlantı yok, credential yok.
Ücretsiz analiz et