Neden dizin arama doğru sayıda satır tahmin edebilir ve sıralama operatörü edemiyor?

Yüklemede bir işlevi kullanan bir sorgu var, böyle bir şey:

commentType = 'EL'
AND commentDateTime >= DATEADD(month,datediff(month,0,getdate()) - 13,0)

40K satır olan commentType üzerinde filtrelenmiş bir dizin var ve sorguyu çalıştırdığınızda, dizin arama için tahmini satır sayısı çok doğru (yaklaşık 11 K), ama sonraki adım (sıralama operatörü) tamamen istatistikleri ve yok sayar filtrelenmiş dizindeki toplam satır sayısını tahmin eder.

Bu neden oluyor? Hırsızlığın temellerini biliyorum ve sadece akıl sağlığını yerine gerçek bir tarihe (2014-01-01) ve voila'ya göre akıl sağlığı için test ettim ... Sıra sıra sayısını doğru tahmin etmeye başladı ...

Bu neden oluyor ve nasıl düzeltebilirim? Sabit bir tarihi geçemem ...

DATEDIFF argümanlarından ikisini değiştiren bir tahminci hatası nedeniyle tahminlerinizin yanlış olduğuna inanıyorum. Burada bunun hakkında konuşuyorum:

• Performans Sürprizleri ve Varsayımlar: DATEDIFF

Geçici çözüm, DATEDIFF (2008+) kullanmadan 13 ay önceki ilk günü hesaplamaktır:

DATEADD(MONTH, -13, DATEADD(DAY, 1-DATEPART(DAY,GETDATE()), CONVERT(DATE, GETDATE()));

Ben değilim pozitif (Filtrelenmeyen endeksler ile test etmedim, ve eminim sıralama aslında ne yaptığını değilim ya tahminini hitap edecek o planı ve / veya sorgunun dinlenmeden farklı tahminini sahip olmasının ).

Microsoft'un önerdiği düzeltme TF 4199 kullanmaktır, ancak burada yapmanız gerekenin bu olduğundan emin değilim:

• Connect # 630583:> dateiff içeren durumla ilgili yanlış tahmin

Başka bir seçenek, aşağıdaki KB makalesinde düzeltildiğini iddia ettikleri için kullandığınız SQL Server sürümü için mutlak en son SP / CU'da olduğunuzdan emin olmaktır (yine de TF 4199'un kullanılmasını gerektirecektir) 2014 veya daha iyisi değilseniz):

• Düzeltme # 2481274: Düzeltme: DATEDIFF işlevini kullanan bir sorgu, SQL Server 2005 veya SQL Server 2008 veya SQL Server 2008 R2'de yavaş çalışabilir

Düzeltme aşağıdaki yapılarla elde edilebilir:

• 2005 SP3 CU 15 (> = 9.00.4325 VE <= 9.00.4999)
• 2005 SP4 CU 2 (> = 9.00.5259)
• 2008 SP1 PB 13 (> = 10.00.2816.00 VE <= 10.00.3999)
• 2008 SP2 CU 3 (> = 10.00.4279.00 VE <= 10.00.5499)
• 2008 SP3 ve SP4 uzantısı ile (> = 10.00.5500)
• 2008 R2 CU 7 (10.50.1777.0)
• 2008 R2 SP1 CU 3 (> = 10.50.2769.0 VE <= 10.50.3999)
• 2008 R2 SP2 ve SP3 uzantısı ile (> = 10.50.4000)
• Uzantıya göre 2012, 2014, 2016 (> = 11,0)

(Bir dahaki sefere, lütfen SELECT @@VERSIONsorunuzun sonuçlarını ekleyin.)

KB makalesinde, DATEDIFF'in senaryolarınızda olanların tam tersi olan satır sayısını hafife alabileceğini söylediğini göreceğim . Bu, düzeltmelerin sizin için geçerli olmadığı anlamına gelmez; Tahminler verilere ve baktığınız aralığa bağlı olarak her iki şekilde de gidebileceğinden, KB makale ifadelerinin yanlış olduğunu düşünüyorum.

Yukarıdaki blog yazım, değiştirmenin artık 2014 ve sonrasında gerçekleşmediğini doğruladı. Güvende olmak için, muhtemelen DATEDIFF'i yükleminizden çıkaracağım ve aralığınızın başlangıcını hesaplamak için farklı bir yöntem kullanacağım. Ben 4199 overkill veya kötü takas önlemek için dinamik SQL kullanarak önermiyoruz.