Yavaş bir sorguyu yalnızca sorgu metnine bakarak düzeltmek çoğu zaman tahmine dayanır. Execution plan, SQL Server'ın veriye hangi sırayla ulaştığını, hangi join algoritmasını seçtiğini ve işlemler arasında kaç satır beklediğini gösterir. Amaç en pahalı görünen ikonu hemen yok etmek değil, optimizer tahminleri ile gerçek çalışma arasındaki farkı bulmaktır.

Actual ve estimated plan farkı

Estimated plan sorguyu çalıştırmadan optimizer tahminlerini gösterir; production üzerinde veri değiştirmeden inceleme yapmak için yararlıdır. Actual plan ise sorguyu çalıştırır ve gerçek satır sayıları gibi çalışma zamanı bilgilerini ekler. Estimated Rows ile Actual Rows arasında büyük fark varsa istatistikler eski olabilir, filtrelenmiş veri dağılımı yanlış modellenmiş olabilir veya parametre sniffing etkisi bulunabilir.

Örnek satış sorgusunu analiz etmek

Aşağıdaki sorgu müşteri ve tarih aralığına göre sipariş arıyor. Plan üzerinde Orders tablosunda scan görülmesi tek başına hata değildir; dönen satır oranı ve okunan sayfa miktarı birlikte değerlendirilmelidir.

SELECT o.Id, o.OrderDate, o.TotalAmount
FROM dbo.Orders AS o
WHERE o.CustomerId = @CustomerId
  AND o.OrderDate >= @StartDate
  AND o.OrderDate < @EndDate
ORDER BY o.OrderDate DESC;

CREATE INDEX IX_Orders_CustomerId_OrderDate
ON dbo.Orders(CustomerId, OrderDate DESC)
INCLUDE (TotalAmount);

Bileşik indeks eşitlik filtresi olan CustomerId ile başlar, ardından tarih aralığını taşır. TotalAmount INCLUDE bölümünde bulunduğu için sorgu çoğu durumda ana tabloya key lookup yapmadan karşılanabilir. Yine de indeks eklemeden önce Query Store üzerinden sorgunun sıklığını ve yazma maliyetini ölçmek gerekir.

Plan inceleme sırası

1. Önce sorgunun toplam süre, CPU, logical read ve dönen satır değerlerini kaydedin.
2. Planı sağdan sola izleyerek verinin hangi operatörlerden geçtiğini anlayın.
3. Estimated ve Actual Rows farkı yüksek operatörleri işaretleyin.
4. Sort, hash spill ve key lookup uyarılarını gerçek çalışma bilgileriyle değerlendirin.
5. Değişiklik sonrası aynı parametrelerle ölçüm yapıp sonucu Query Store'da karşılaştırın.

Yanlış yaklaşımlar

• Plan maliyet yüzdesini gerçek süre sanmak; bu değer optimizer tahminidir.
• Her scan operatörünü indeks ekleyerek seek'e çevirmeye çalışmak.
• Test verisiyle hızlı çalışan sorgunun production veri dağılımında da aynı davranacağını varsaymak.

Sonuç

Execution plan bir reçete değil, SQL Server'ın kararlarını açıklayan kanıttır. Sağlıklı tuning; plan, IO ölçümleri, Query Store geçmişi ve iş yükü bilgisi birlikte kullanıldığında yapılır. Önce yanlış satır tahminlerini ve gereksiz veri okumayı azaltın, ardından indeks veya sorgu değişikliğinin yazma maliyetini de ölçerek karar verin.