tăng hiệu suất truy vấn bằng cách loại bỏ toán tử băm khớp nối bên trong


9

Trong khi cố gắng áp dụng nội dung của câu hỏi dưới đây vào tình huống của riêng tôi, tôi hơi bối rối vì làm thế nào tôi có thể thoát khỏi toán tử Hash Match (Tham gia bên trong) nếu có thể.

Hiệu suất truy vấn SQL Server - loại bỏ nhu cầu đối với Hash Match (Tham gia bên trong)

Tôi nhận thấy chi phí 10% và tự hỏi liệu tôi có thể giảm được không. Xem kế hoạch truy vấn dưới đây.

nhập mô tả hình ảnh ở đây

Công việc này xuất phát từ một truy vấn mà tôi phải điều chỉnh ngày hôm nay:

SELECT c.AccountCode, MIN(d.CustomerSID) 
FROM   Stage.Customer c 
INNER JOIN Dimensions.Customer d  ON c.Email = d.Email
                                  OR (
                                          c.HomePostCode = d.HomePostCode
                                       AND c.StrSurname = d.strSurname
                                                                    )
GROUP BY c.AccountCode

và sau khi thêm các chỉ mục này:

---------------------------------------------------------------------
-- Create the indexes
---------------------------------------------------------------------

CREATE NONCLUSTERED INDEX IDX_Stage_Customer_HOME_SURNAME_INCL
ON Stage.Customer(HomePostCode ,strSurname)
INCLUDE (AccountCode)
--WHERE HASEMAIL = 0
--WITH (ONLINE=ON, DROP_EXISTING = ON)
go


CREATE NONCLUSTERED INDEX IDX_Dimensions_Customer_HOME_SURNAME_INCL
ON Dimensions.Customer(HomePostCode ,strSurname)
INCLUDE (AccountCode,CustomerSID)
--WHERE HASEMAIL = 0
--WITH (ONLINE=ON, DROP_EXISTING = ON)
go



CREATE NONCLUSTERED INDEX IDX_Stage_Customer_EMAIL_INCL
ON Stage.Customer(EMAIL)
INCLUDE (AccountCode)
--WHERE HASEMAIL = 1
--WITH (ONLINE=ON, DROP_EXISTING = ON)
go


CREATE NONCLUSTERED INDEX IDX_Dimensions_Customer_EMAIL_INCL
ON Dimensions.Customer(EMAIL)
INCLUDE (AccountCode,CustomerSID)
--WHERE HASEMAIL = 1
--WITH (ONLINE=ON, DROP_EXISTING = ON)
go

đây là truy vấn mới:

----------------------------------------------------------------------------
-- new query 
----------------------------------------------------------------------------

SELECT * 
FROM (    
SELECT AccountCode
     ,RO=ROW_NUMBER () OVER (PARTITION BY AccountCode ORDER BY CustomerSID)
     --,CustomerSID=MIN(CustomerSID) OVER (PARTITION BY AccountCode ORDER BY AccountCode)
       ,CustomerSID
FROM (    
          SELECT c.AccountCode, D.CustomerSID
       FROM   Stage.Customer c 
       INNER JOIN Dimensions.Customer d  ON c.Email = d.Email

          UNION ALL

          SELECT c.AccountCode, D.CustomerSID
       FROM   Stage.Customer c 
       INNER JOIN Dimensions.Customer d  ON c.HomePostCode = d.HomePostCode
                                        AND c.StrSurname = d.strSurname
) RADHE
) R1
WHERE RO = 1

Điều này đã giảm thời gian thực hiện truy vấn từ 8 phút xuống còn 1 giây.

Mọi người đều vui vẻ, nhưng tôi vẫn muốn biết liệu tôi có thể làm được nhiều việc hơn không, bằng cách nào đó loại bỏ toán tử khớp băm.

Tại sao nó ở đó ngay từ đầu, tôi khớp tất cả các trường, tại sao lại băm?

Câu trả lời:


14

các liên kết sau đây sẽ cung cấp một nguồn kiến ​​thức tốt về các kế hoạch thực hiện.

Từ những điều cơ bản về kế hoạch thực hiện - Sự nhầm lẫn của Hash Match tôi đã tìm thấy:

Từ http://sqlinthewild.co.za/index.php/2007/12/30/execut-plan-operations-joins/

"Tham gia băm là một trong những hoạt động tham gia đắt tiền hơn, vì nó yêu cầu tạo ra một bảng băm để thực hiện tham gia. Điều đó nói rằng, đó là sự tham gia tốt nhất cho các đầu vào lớn, chưa được sắp xếp. của các tham gia

Đầu tiên hàm băm đọc một trong các đầu vào và băm cột tham gia và đặt giá trị băm và cột kết quả vào một bảng băm được xây dựng trong bộ nhớ. Sau đó, nó đọc tất cả các hàng trong đầu vào thứ hai, băm các hàng đó và kiểm tra các hàng trong nhóm băm kết quả cho các hàng tham gia. "

liên kết đến bài viết này:

http://bloss.msdn.com/b/craigfr/archive/2006/08/10/687630.aspx

Bạn có thể giải thích kế hoạch thực hiện này? cung cấp những hiểu biết tốt về kế hoạch thực hiện với, không cụ thể đối với băm khớp nhưng có liên quan.

Quét liên tục là một cách để SQL Server tạo ra một nhóm mà sau đó nó sẽ đặt một cái gì đó trong kế hoạch thực hiện. Tôi đã đăng một lời giải thích kỹ lưỡng hơn về nó ở đây . Để hiểu quét liên tục để làm gì, bạn phải xem xét thêm về kế hoạch. Trong trường hợp này, đó là toán tử vô hướng tính toán đang được sử dụng để điền vào không gian được tạo bởi quá trình quét liên tục.

Các toán tử Compute Scalar đang được tải lên với NULL và giá trị 1045876, vì vậy chúng rõ ràng sẽ được sử dụng với Loop Join trong nỗ lực lọc dữ liệu.

Phần thực sự thú vị là kế hoạch này là Trivial. Nó có nghĩa là nó đã trải qua một quá trình tối ưu hóa tối thiểu. Tất cả các hoạt động đang dẫn đến Khoảng thời gian hợp nhất. Điều này được sử dụng để tạo ra một tập hợp các toán tử so sánh tối thiểu cho tìm kiếm chỉ mục ( chi tiết về điều đó ở đây ).

Trong câu hỏi này: Tôi có thể lấy SSMS để hiển thị cho tôi chi phí truy vấn thực tế trong ngăn kế hoạch Thực hiện không? Tôi đang khắc phục các sự cố về hiệu suất trên quy trình được lưu trữ nhiều tầng trong SQL Server. Tôi muốn biết phần nào tôi nên dành thời gian trên.

Tôi hiểu từ Làm cách nào để đọc Chi phí truy vấn và luôn luôn là phần trăm? rằng ngay cả khi SSMS được yêu cầu bao gồm Kế hoạch thực hiện thực tế, số liệu "Chi phí truy vấn (so với lô)" vẫn dựa trên ước tính chi phí, có thể khác xa với thực tế

Đo lường hiệu suất truy vấn: Kế hoạch thực hiện của kế hoạch Truy vấn Chi phí Truy vấn so với Thời gian thực hiện Cung cấp thông tin tốt khi bạn cần so sánh hiệu suất của 2 truy vấn khác nhau.

Trong Đọc kế hoạch Thực thi Máy chủ SQL, bạn có thể tìm thấy các mẹo hay để đọc kế hoạch thực hiện.

Các câu hỏi / câu trả lời khác mà tôi thực sự thích vì chúng có liên quan đến chủ đề này và để tham khảo cá nhân tôi muốn trích dẫn là:

Cách tối ưu hóa truy vấn T-SQL bằng Kế hoạch thực hiện

sql có thể tạo ra một kế hoạch tốt cho thủ tục này?

Kế hoạch thực hiện khác nhau cho cùng một câu lệnh SQL

Khi sử dụng trang web của chúng tôi, bạn xác nhận rằng bạn đã đọc và hiểu Chính sách cookieChính sách bảo mật của chúng tôi.
Licensed under cc by-sa 3.0 with attribution required.