Perkiraan kardinalitas buruk berasal dari rencana eksekusi SSMS

Saya harus berterima kasih kepada beberapa orang untuk pembaruan terbaru ke SQL Sentry Plan Explorer. Brooke Philpott (@Macromullet) dan Greg Gonzalez (blog | @SQLsensei), tentu saja, untuk R &D dan untuk menggali kode dan memilahnya. Tetapi juga kepada Paul White (blog | @SQL_kiwi) karena gigih dalam membantu kami memvalidasi perbaikan.

Masalah yang ditemukan Paul adalah bahwa SQL Server 2008+ mengacaukan perkiraan kardinalitas pada kueri tertentu ketika pencarian kunci atau RID terlibat. Saya akan menyerahkan penjelasan yang lebih dalam ke posting blog Paul dan bug yang dia ajukan di Connect, tetapi singkatnya, kami mengambil perkiraan yang salah mengartikan ini, mempercayainya, dan mengekstrapolasinya untuk menunjukkan kepada Anda informasi yang "lebih baik". Sayangnya, seperti yang dijelaskan Paul, kami ditipu.

Paul menunjukkan kueri berikut terhadap salinan AdventureWorks 2005.

SELECT
    th.ProductID,
    th.TransactionID,
    th.TransactionDate
FROM Production.TransactionHistory AS th 
WHERE 
    th.ProductID = 1 
    AND th.TransactionDate BETWEEN '20030901' AND '20031231';

Management Studio menghasilkan rencana berikut, seperti yang dijelaskan Paul:

Di Plan Explorer, kami mencoba membantu dengan mengalikan perkiraan jumlah baris (dibulatkan menjadi 17) dengan jumlah eksekusi (45), dan menghasilkan 765:

Untuk sebagian besar operator, pendekatan ini menghasilkan data yang benar, tetapi karena bug ini di SQL Server, ini tidak benar untuk pencarian kunci/RID. Kami telah menyesuaikannya, dan merilis perbaikan yang sesuai di 7.2.42.0 (unduh sekarang!). Rencana grafis sekarang dengan benar menunjukkan jumlah baris yang benar untuk kedua perkiraan:

Dan sebenarnya:

Saya akan mengulangi peringatan Paul:Hati-hati dengan perkiraan kardinalitas yang buruk saat predikat diterapkan sebagai bagian dari pencarian.

Ada beberapa masalah yang lebih kompleks yang disebabkan oleh perkiraan yang menyesatkan ini, yang juga telah kami bahas. Saya akan menulis blog tentang beberapa di antaranya dalam posting lanjutan – untuk posting ini saya hanya ingin menunjukkan bahwa kami dengan cepat menyelesaikan masalah spesifik yang disoroti Paul dalam postingnya.