Mengapa indeks pencarian saya dapat memperkirakan jumlah baris yang tepat dan operator sortir tidak bisa?

Saya memiliki kueri yang menggunakan fungsi pada predikat, seperti ini:

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

Saya memiliki indeks yang difilter pada commentType yang memiliki baris 40K dan ketika saya menjalankan kueri, perkiraan jumlah baris untuk Index Seek sangat akurat (sekitar 11K), tetapi untuk langkah berikutnya (operator sortir) itu benar-benar mengabaikan statistik dan hanya perkirakan jumlah total baris dalam indeks yang difilter.

Mengapa ini terjadi? Saya tahu dasar-dasar tentang sargability , dan saya telah menguji hanya demi kewarasan mengganti dateadd dengan tanggal aktual (2014-01-01) dan voila ... Semacam itu mulai menebak jumlah baris dengan benar ...

Mengapa ini terjadi dan bagaimana saya bisa memperbaikinya? Saya tidak bisa melewati tanggal yang pasti ...

Saya percaya perkiraan Anda salah karena bug penaksir yang menukar dua argumen DATEDIFF. Saya membicarakan hal ini di sini:

• Kejutan dan Asumsi Kinerja: DATEDIFF

Solusinya adalah menghitung hari pertama 13 bulan yang lalu tanpa menggunakan DATEDIFF (2008+):

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

Saya tidak yakin akan membahas perkiraan (saya belum menguji dengan indeks yang difilter, dan saya tidak yakin apa yang sebenarnya dilakukan atau mengapa ia memiliki perkiraan yang berbeda tanpa rencana dan / atau sisa kueri ).

Perbaikan yang disarankan Microsoft adalah menggunakan TF 4199, tapi saya tidak begitu yakin itulah yang perlu Anda lakukan di sini:

• Hubungkan # 630583: Perkiraan salah dengan kondisi yang mencakup> Dateiff

Opsi lain adalah untuk memastikan Anda berada pada SP / CU terbaru mutlak untuk versi SQL Server apa pun yang Anda gunakan, karena mereka mengklaim itu diperbaiki dalam artikel KB berikut (meskipun ini masih akan memerlukan penggunaan TF 4199 kecuali Anda berada di 2014 atau lebih baik):

• KB # 2481274: FIX: Kueri yang menggunakan fungsi DATEDIFF dapat berjalan lambat di SQL Server 2005 atau di SQL Server 2008 atau di SQL Server 2008 R2

Perbaikan dapat diperoleh dengan build berikut:

• 2005 SP3 CU 15 (> = 9.00.4325 AND <= 9.00.4999)
• 2005 SP4 CU 2 (> = 9.00.5259)
• 2008 SP1 CU 13 (> = 10.00.2816.00 DAN <= 10.00.3999)
• 2008 SP2 CU 3 (> = 10.00.4279.00 DAN <= 10.00.5499)
• Dengan ekstensi 2008 SP3 & SP4 (> = 10.00.5500)
• 2008 R2 CU 7 (10.50.1777.0)
• 2008 R2 SP1 CU 3 (> = 10.50.2769.0 DAN <= 10.50.3999)
• Dengan ekstensi 2008 R2 SP2 & SP3 (> = 10.50.4000)
• Dengan ekstensi 2012, 2014, 2016 (> = 11.0)

(Lain kali, harap sertakan hasil SELECT @@VERSIONdalam pertanyaan Anda.)

Saya akan perhatikan bahwa artikel KB mengatakan bahwa DATEIFF dapat meremehkan jumlah baris, yang merupakan kebalikan dari apa yang terjadi dalam skenario Anda. Itu tidak berarti perbaikan tidak berlaku untuk Anda; Saya pikir kata-kata artikel KB tidak akurat, karena perkiraannya bisa tergantung pada data dan rentang yang Anda lihat.

Posting blog saya di atas mengkonfirmasi bahwa pertukaran tidak lagi terjadi pada tahun 2014 ke atas. Agar aman, saya mungkin hanya akan menghapus DATEIFF dari predikat Anda dan menggunakan metode yang berbeda untuk menghitung awal rentang Anda. Saya tidak menyarankan berlebihan dari 4199 atau menggunakan SQL dinamis untuk mencegah pertukaran yang buruk.