Thuộc tính mới “Đọc hàng thực tế” trong kế hoạch thực thi (trong SQL Server Management Studio được hiển thị là “Số hàng đã đọc”) là một bổ sung đáng hoan nghênh cho bộ điều chỉnh hiệu suất. Nó giống như có một siêu năng lực mới, để có thể cho biết tầm quan trọng của Vị từ tìm kiếm v Vị từ dư trong toán tử Seek. Tôi thích điều này, vì nó có thể thực sự quan trọng đối với việc truy vấn.
Hãy xem xét hai truy vấn mà tôi đang thực hiện với AdventureWorks2012. Chúng rất đơn giản - một danh sách liệt kê những người được gọi là John S và danh sách kia liệt kê những người được gọi là J Smith. Giống như tất cả các danh bạ tốt, chúng tôi có một chỉ mục trên LastName, FirstName.
select FirstName, LastName from Person.Person where LastName like 'S%' and FirstName = 'John'; select FirstName, LastName from Person.Person where LastName = 'Smith' and FirstName like 'J%';
Trong trường hợp bạn tò mò, tôi lấy lại 2 hàng từ hàng đầu tiên và 14 hàng lùi lại từ hàng thứ hai. Tôi thực sự không quan tâm đến kết quả, tôi quan tâm đến kế hoạch thực hiện.
Hãy xem điều gì đang xảy ra. Tôi đã mở một bản sao cũ hơn của SQL Sentry Plan Explorer và mở các kế hoạch của tôi song song với nhau. Thật ngẫu nhiên - tôi đã chạy cả hai truy vấn cùng nhau và vì vậy cả hai gói đều nằm trong cùng một tệp .sqlplan. Nhưng tôi có thể mở cùng một tệp hai lần trong PE và vui vẻ đặt chúng cạnh nhau trong các nhóm tab.
Tuyệt quá. Họ trông thật giống nhau! Tôi có thể thấy rằng Tìm kiếm ở bên trái đang tạo ra hai hàng thay vì mười bốn - rõ ràng đây là truy vấn tốt hơn.
Nhưng với một cửa sổ lớn hơn, tôi sẽ thấy nhiều thông tin hơn và thật may mắn là tôi đã chạy hai truy vấn trong cùng một đợt.
Bạn có thể thấy rằng truy vấn thứ hai, tạo ra 14 hàng thay vì 2 hàng, ước tính chiếm hơn 80% chi phí! Nếu tôi chạy các truy vấn riêng lẻ, mỗi truy vấn sẽ hiển thị cho tôi 100%.
Bây giờ, hãy so sánh với bản phát hành mới nhất của Plan Explorer.
Thứ nhảy ra với tôi ngay lập tức là lời cảnh báo. Hãy xem xét kỹ hơn một chút.
Cảnh báo cho biết “Hoạt động gây ra IO tồn dư. Số hàng thực tế được đọc là 2.130, nhưng số hàng được trả về là 2 ” Chắc chắn rồi, ở phần tiếp theo, chúng tôi thấy “Hàng thực tế đã đọc” cho biết 2,130 và hàng thực tế là 2.
Ái chà! Để tìm những hàng đó, chúng ta phải xem qua 2.130?
Bạn thấy đấy, cách mà Tìm kiếm chạy là bắt đầu bằng cách nghĩ về Vị từ Tìm kiếm. Đó là cách thúc đẩy chỉ mục một cách độc đáo và thực sự khiến hoạt động trở thành một Tìm kiếm. Nếu không có Dự đoán Tìm kiếm, hoạt động sẽ trở thành một Quét. Bây giờ, nếu Predicate tìm kiếm này được đảm bảo chỉ có nhiều nhất một hàng (chẳng hạn như khi nó có toán tử bình đẳng trên một chỉ mục duy nhất), thì chúng ta có một tìm kiếm Singleton. Nếu không, chúng tôi có Quét phạm vi và phạm vi này có thể có Tiền tố, Bắt đầu và Kết thúc (nhưng không nhất thiết phải có cả Bắt đầu và Kết thúc). Điều này xác định các hàng trong bảng mà chúng tôi quan tâm đến Tìm kiếm.
Nhưng "quan tâm đến" không nhất thiết có nghĩa là "được trả lại", bởi vì chúng tôi có thể còn nhiều việc phải làm. Công việc đó được mô tả trong Vị từ khác, thường được gọi là Vị từ dư.
Bây giờ, vị trí dư thừa đó thực sự có thể đang thực hiện hầu hết công việc. Chắc chắn là ở đây - nó đang lọc mọi thứ từ 2.130 hàng xuống chỉ còn 2.
Quét Phạm vi bắt đầu trong chỉ mục tại “John S”. Chúng tôi biết rằng nếu có "John S", đây phải là hàng đầu tiên có thể đáp ứng toàn bộ. “Ian S” không được. Vì vậy, chúng tôi có thể tìm kiếm trong chỉ mục tại thời điểm đó để bắt đầu Quét phạm vi của chúng tôi. Nếu chúng ta nhìn vào Plan XML, chúng ta có thể thấy điều này một cách rõ ràng.
Lưu ý rằng chúng tôi không có Tiền tố. Điều đó áp dụng khi bạn có một bằng nhau trong cột đầu tiên trong chỉ mục. Chúng tôi chỉ có StartRange và EndRange. Bắt đầu của phạm vi là Loại quét "Lớn hơn hoặc Bằng" (GE), tại giá trị "S, John" (cột tham chiếu ngoài màn hình là LastName, FirstName) và Cuối phạm vi là "Nhỏ hơn" ( LT) giá trị T. Khi quá trình quét chạm đến T, nó đã hoàn tất. Không còn gì để làm nữa. Seek hiện đã hoàn thành Quét phạm vi của nó. Và trong trường hợp này, nó trả về 2.130 hàng!
Ngoại trừ việc nó không thực sự trả về 2.130 hàng, nó chỉ đọc 2.130 hàng. Những cái tên như Barry Sai và Ken Sánchez được đọc, nhưng chỉ những cái tên đáp ứng được lần kiểm tra tiếp theo mới được trả về - Vị từ còn lại đảm bảo rằng Tên đầu tiên là John.
Mục nhập Đọc hàng thực tế trong thuộc tính của toán tử Tìm kiếm chỉ mục cho chúng ta thấy giá trị này là 2,130. Và mặc dù nó hiển thị trong các bản phát hành trước đó của Plan Explorer, nhưng chúng tôi không nhận được cảnh báo về nó. Đó là điều tương đối mới.
Truy vấn thứ hai của chúng tôi (tìm kiếm J Smith) đẹp hơn nhiều và có lý do tại sao nó được ước tính rẻ hơn 4 lần.
Ở đây chúng ta biết chính xác LastName (Smith), và Range Scan nằm trên FirstName (J%).
Đây là nơi xuất hiện Tiền tố.
Chúng tôi thấy rằng Tiền tố của chúng tôi là một toán tử Equality (=, ScanType =”EQ”) và LastName đó phải là Smith. Chúng tôi thậm chí chưa xem xét Bắt đầu hoặc Kết thúc phạm vi, nhưng Tiền tố cho chúng tôi biết rằng phạm vi được bao gồm trong phần của chỉ mục nơi LastName là Smith. Bây giờ chúng ta có thể tìm thấy các hàng> =J và
Vẫn có một Vị từ dư ở đây, nhưng điều này chỉ đảm bảo rằng “LIKE J%” thực sự được kiểm tra. Mặc dù đối với chúng tôi có vẻ trực quan rằng “LIKE J%” chính xác tương đương với “> =J và
Trước Gói dịch vụ 3 của SQL Server 2012, chúng tôi không có thuộc tính này và để cảm nhận sự khác biệt giữa Đọc hàng thực và Hàng thực, chúng ta cần sử dụng cờ theo dõi 9130. Đây là hai kế hoạch đó với TF đó được bật:
Bạn có thể thấy không có cảnh báo nào lần này vì toán tử Seek đang trả về tất cả 2130 hàng. Tôi nghĩ rằng nếu bạn đang sử dụng phiên bản SQL Server hỗ trợ Đọc hàng thực tế này, bạn nên ngừng sử dụng cờ theo dõi 9130 trong các cuộc điều tra của mình và thay vào đó hãy bắt đầu xem xét các cảnh báo trong Plan Explorer. Nhưng trên hết, hãy hiểu cách các nhà điều hành của bạn thực hiện công việc của họ, bởi vì khi đó bạn sẽ có thể hiểu liệu bạn có hài lòng với kế hoạch hay không hay bạn cần phải hành động.
Trong một bài đăng khác, tôi sẽ cho bạn thấy một tình huống khi bạn có thể thích xem Hàng thực tế được đọc cao hơn Hàng thực tế.
@rob_farley
