Ước tính bản số sai từ các gói SSMS - redux

Hơn ba năm trước, tôi đã đăng về một bản sửa lỗi cho Plan Explorer liên quan đến ước tính bản số kém mà XML Showplan của SQL Server đang tạo ra, trong trường hợp tra cứu khóa / RID với một vị từ bộ lọc trong SQL Server 2008 trở lên. Tôi nghĩ sẽ rất thú vị khi nhìn lại và đi vào chi tiết hơn một chút về một trong những kế hoạch này và các lần lặp lại mà chúng tôi đã trải qua để đảm bảo chúng tôi đang hiển thị các chỉ số chính xác, bất kể những gì Management Studio hiển thị. Một lần nữa, công việc này phần lớn được thực hiện bởi Brooke Philpott (@MacroMullet) và Greg Gonzalez (@SQLsensei) và với sự đóng góp tuyệt vời từ Paul White (@SQL_Kiwi).

Điều này khá giống với truy vấn mà tôi đã trình bày trong bài đăng trước đó của mình, đến từ Paul (và sẽ mất một số công việc để tái tạo chính xác trong các phiên bản hiện đại của AdventureWorks, nơi ít nhất ngày giao dịch đã thay đổi):

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';

Kế hoạch từ Management Studio trông đủ chính xác:

Tuy nhiên, nếu bạn nhìn kỹ hơn, có vẻ như ShowPlan đã đẩy số lần thực thi ước tính từ tra cứu khóa lên thẳng số hàng ước tính cho lần trao đổi cuối cùng:

Thoạt nhìn, sơ đồ mặt bằng đồ họa trong Plan Explorer trông khá giống với sơ đồ mà SSMS tạo ra:

Bây giờ, trong quá trình phát triển Plan Explorer, chúng tôi đã phát hiện ra một số trường hợp ShowPlan không hoàn toàn hiểu chính xác phép toán của nó. Ví dụ rõ ràng nhất là tỷ lệ phần trăm cộng lên đến hơn 100%; chúng ta hiểu đúng điều này trong trường hợp SSMS bị tắt một cách vô lý (ngày nay tôi thấy điều này ít thường xuyên hơn trước đây, nhưng nó vẫn xảy ra).

Một trường hợp khác là bắt đầu từ SQL Server 2008, SSMS bắt đầu đặt tổng số hàng ước tính thay vì hàng trên mỗi lần thực thi cùng với tra cứu, nhưng chỉ trong trường hợp một vị từ được đẩy lên tra cứu (chẳng hạn như trường hợp trong lỗi này được Paul báo cáo, và quan sát gần đây hơn của Joey D'Antoni). Trong các phiên bản trước của SQL Server (và với các hàm và cuộn), chúng tôi thường hiển thị số lượng hàng ước tính đến từ một tra cứu bằng cách nhân số hàng ước tính cho mỗi lần thực thi (thường là 1) với số hàng ước tính theo SSMS. Nhưng với sự thay đổi này, chúng ta sẽ đếm quá nhiều, vì toán tử hiện đã thực hiện phép toán đó. Vì vậy, trong các phiên bản trước của Plan Explorer, so với 2008+, bạn sẽ thấy các chi tiết này trong chú giải công cụ, dòng trình kết nối hoặc trong các lưới khác nhau:

(1.721 đến từ đâu? 67,5 lần thực thi ước tính x 25,4927 hàng ước tính.)

Trở lại năm 2012, chúng tôi đã khắc phục một phần của vấn đề này bằng cách không thực hiện phép toán này nữa và chỉ dựa vào số lượng hàng ước tính từ tra cứu khóa. Điều này gần như đúng, nhưng chúng tôi vẫn dựa trên số lượng hàng ước tính mà ShowPlan cung cấp cho chúng tôi để trao đổi cuối cùng:

Chúng tôi cũng đã nhanh chóng giải quyết vấn đề này trong phiên bản 7.2.42.0 (phát hành vào Hallowe'en 2012) và hiện tại chúng tôi cảm thấy rằng chúng tôi đang cung cấp thông tin chính xác hơn nhiều so với Management Studio (mặc dù chúng tôi sẽ theo dõi lỗi này từ Paul) :

Điều này rõ ràng đã xảy ra từ lâu, nhưng tôi vẫn nghĩ sẽ rất thú vị khi chia sẻ. Chúng tôi tiếp tục thực hiện các cải tiến đối với Plan Explorer để cung cấp cho bạn thông tin chính xác nhất có thể và tôi sẽ chia sẻ thêm một số tiện ích này trong các bài đăng sắp tới.