Lebih dari tiga tahun yang lalu sekarang, saya memposting tentang perbaikan ke Plan Explorer mengenai perkiraan kardinalitas buruk yang diproduksi oleh Showplan XML SQL Server, dalam kasus pencarian kunci/RID dengan predikat filter di SQL Server 2008 dan di atasnya. Saya pikir akan menarik untuk melihat ke belakang dan masuk ke sedikit lebih detail tentang salah satu rencana ini dan iterasi yang kami lalui untuk memastikan kami menampilkan metrik yang benar, terlepas dari apa yang ditampilkan oleh Management Studio. Sekali lagi, pekerjaan ini sebagian besar dilakukan oleh Brooke Philpott (@MacroMullet) dan Greg Gonzalez (@SQLsensei) dan dengan masukan yang bagus dari Paul White (@SQL_Kiwi).
Ini sangat mirip dengan pertanyaan yang saya sajikan di posting saya sebelumnya, yang berasal dari Paul (dan yang akan membutuhkan beberapa pekerjaan untuk mereproduksi persis di versi modern AdventureWorks, di mana setidaknya tanggal transaksi telah berubah):
SELECT
th.ProductID,
p.Name,
th.TransactionID,
th.TransactionDate
FROM Production.Product AS p
JOIN Production.TransactionHistory AS th ON
th.ProductID = p.ProductID
WHERE
p.ProductID IN (1, 2)
AND th.TransactionDate BETWEEN '20070901' AND '20071231'; Rencana dari Management Studio terlihat cukup tepat:
Namun, jika Anda melihat lebih dekat, tampaknya ShowPlan telah mendorong perkiraan jumlah eksekusi dari pencarian kunci langsung ke perkiraan jumlah baris untuk pertukaran akhir:
Sekilas, diagram rencana grafis di Plan Explorer terlihat sangat mirip dengan rencana yang dihasilkan SSMS:
Sekarang, dalam proses pengembangan Plan Explorer, kami telah menemukan beberapa kasus di mana ShowPlan tidak cukup mendapatkan matematika yang benar. Contoh yang paling jelas adalah persentase menambahkan hingga lebih dari 100%; kami melakukan ini dengan benar dalam kasus di mana SSMS sangat tidak aktif (saya melihat ini lebih jarang hari ini daripada dulu, tetapi itu masih terjadi).
Kasus lain adalah di mana, mulai dari SQL Server 2008, SSMS mulai menempatkan total perkiraan baris alih-alih baris per eksekusi bersama dengan pencarian, tetapi hanya dalam kasus di mana predikat didorong ke pencarian (seperti kasus dalam bug ini yang dilaporkan oleh Paul, dan pengamatan yang lebih baru ini oleh Joey D'Antoni). Di versi SQL Server sebelumnya (dan dengan fungsi dan spool), kami biasanya akan menampilkan perkiraan jumlah baris yang keluar dari pencarian dengan mengalikan perkiraan baris per eksekusi (biasanya 1) dengan perkiraan jumlah baris menurut SSMS. Tetapi dengan perubahan ini, kita akan menghitung secara berlebihan, karena operator sekarang sudah melakukan perhitungan itu. Jadi, di versi Plan Explorer sebelumnya, dibandingkan 2008+, Anda akan melihat detail ini di tooltips, baris konektor, atau di berbagai grid:
(Dari mana 1.721 berasal? 67,5 perkiraan eksekusi x 25,4927 perkiraan baris.)
Kembali pada tahun 2012, kami memperbaiki sebagian dari masalah ini dengan tidak melakukan operasi matematika ini lagi, dan hanya mengandalkan perkiraan jumlah baris yang keluar dari pencarian kunci. Ini hampir benar, tetapi kami masih mengandalkan perkiraan jumlah baris yang diberikan ShowPlan kepada kami untuk pertukaran terakhir:
Kami dengan cepat mengatasi masalah ini juga, dalam versi 7.2.42.0 (dirilis pada Hallowe'en 2012), dan sekarang merasa kami memberikan informasi yang jauh lebih akurat daripada Management Studio (meskipun kami akan mengawasi bug ini dari Paul) :
Ini jelas terjadi sudah lama sekali, tetapi saya masih berpikir itu akan menarik untuk dibagikan. Kami terus menyempurnakan Plan Explorer untuk memberi Anda informasi seakurat mungkin, dan saya akan membagikan beberapa nugget ini lagi di postingan mendatang.
