I / O cao cho một phần của truy vấn

Tôi có một truy vấn lớn mà tôi đang cố gắng điều chỉnh. Tôi viết rất nhiều truy vấn nhưng chưa thực hiện nhiều điều chỉnh. Tôi đã bao gồm một ảnh chụp màn hình từ SQL Sentry Plan Explorer Free (SSPEF):

I / O cao

Trong phần trên của kế hoạch, bảng pb_WorkRquestLog chứa 229.001 hàng. Tuy nhiên, kế hoạch truy vấn đang hiển thị khoảng. 348 triệu hàng (229.001 x 1.520 lần lặp):

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

Không có mệnh đề where nên truy vấn đang sử dụng Quét chỉ mục cụm. Tôi đã xây dựng lại tất cả các chỉ mục với FULLSCAN và cập nhật tất cả các số liệu thống kê.

Mã mà phần này của kế hoạch đang thực hiện là:

select distinct 
            wrs.ServiceKey 
            , owner.DepartmentName AS GroupName
            , owner.UserName AS UserId
            , owner.WRLCreateDateTime
            , owner.WRLNotes
            , wrx.CreatedDate as WRCreateDateTime
            , wrx.Id
            , wrx.Description 
            , cast(wrx.Notes as varchar(2500)) as Notes
        from    
            prism72ext.dbo.pb_WorkRequestService wrs 
            Join prism72ext.dbo.pb_WorkRequest wrx on (wrs.WorkRequestId = wrx.Id and wrx.Status = 'Incomplete')
            left join (
                select
                    wl.WorkRequestId
                    ,   d.Name AS DepartmentName
                    ,   u.UserName
                    , wl.CreatedDate as WRLCreateDateTime
                    , cast(wl.Notes as varchar(2500)) as WRLNotes
                from
                    (
                        SELECT     
                            MAX( Id ) AS Id
                        FROM          
                                prism72ext.dbo.pb_WorkRequestLog WITH(INDEX(0))
                        GROUP BY 
                            WorkRequestId
                    ) mwl
                    join prism72ext.dbo.pb_WorkRequestLog wl on mwl.Id = wl.Id
                    join prism72Ext.dbo.pb_Department d ON wl.DepartmentId = d.DepartmentId
                    left join prism72Ext.dbo.pb_User u on wl.UserId = u.UserId
                ) owner on wrs.WorkRequestId = owner.WorkRequestId

SSPEF đang báo cáo Kích thước dữ liệu thực tế là gần 5GB, với 3 triệu lượt đọc hợp lý! SSMS báo cáo bảng chỉ có kích thước 16 MB.

Tôi đã điều chỉnh truy vấn từ 4m28 xuống còn 1m35, nhưng giờ tôi bị kẹt. Tôi sẽ biết ơn nếu bất cứ ai có thể chỉ cho tôi đi đúng hướng để giải quyết vấn đề này.

Chỉnh sửa: Ai đó đề nghị thử "TÙY CHỌN (HASH THAM GIA, THAM GIA MERGE)". Điều này đã tạo ra một sự khác biệt lớn. I / O được giảm ồ ạt và truy vấn chạy trong 13 giây.

Có ai thấy bất kỳ vấn đề với giải pháp này?

— Alan T
nguồn

Bình luận không dành cho thảo luận mở rộng; cuộc trò chuyện này đã được chuyển sang trò chuyện .

— Paul White 9

Câu trả lời:

Nếu bạn chưa có, hãy tạo một chỉ mục không bao gồm tổng hợp trên prism72ext.dbo.pb_WorkRequestLog(WorkRequestId, Id DESC)và chạy truy vấn mà không có gợi ý chỉ mục.

Ngoài ra, có lựa chọn bên trong của bạn cho ownertrả về bảng dẫn xuất mwl.WorkRequestIdthay vì ml.WorkRequestId.

— Bruce Dunwiddie
nguồn

Xin chào shriop, tôi có chỉ số đó, nhưng không có DESC. Tôi đã thực hiện những thay đổi mà bạn đề xuất, nhưng nó không tạo ra nhiều khác biệt. Tôi đã cập nhật câu hỏi với một giải pháp. Bạn có thể xem giải pháp và cho biết nếu bạn nghĩ rằng nó là phù hợp.

— Alan T

Nó phụ thuộc vào mức độ cốt lõi đối với hệ thống của bạn truy vấn này. Có lẽ nó khá thích hợp như một giải pháp cho một vấn đề bạn đang cố gắng giải quyết với bối cảnh hạn chế qua internet. Nói chung, các gợi ý luôn luôn phải tránh và có xu hướng "gợi ý" về một vấn đề tiềm ẩn, nhưng có lẽ đó là điều mà tôi sẽ phải ngồi ở máy chủ của bạn trong một giờ hoặc lâu hơn để chạy các truy vấn để giải quyết tốt hơn. Mỗi mặt trăng màu xanh, có xu hướng có vẻ như nó gần như cần một gợi ý, nhưng tôi vẫn cảm thấy rằng nó thậm chí có thể hiển thị những khoảng trống của riêng tôi khi điều đó xảy ra, không phải là về mặt kỹ thuật.

— Bruce Dunwiddie

Nếu nó thực sự là cốt lõi đối với hệ thống của bạn, tôi khuyên bạn nên chuyển "sửa chữa" đó sang sản xuất, nhưng tiếp tục nghiên cứu và hiểu lý do tại sao, tùy thuộc vào thời gian bạn phải đầu tư.

— Bruce Dunwiddie

Có vẻ như bạn đang tìm kiếm "mới nhất" (tức là có mức cao nhất ID) kỷ lục trong pb_WorkRequestLogcho một cụ thể WorkRequestId. Có thể có sự hiện diện của chỉ mục đó phía trên một hàm window ( ROW_NUMBER() OVER (PARTITION BY pb_WorkRequestLog ORDER BY ID DESC) sẽ hoạt động tốt hơn.

— mustaccio

sử dụng gợi ý INDEX (0) buộc quét chỉ mục cụm. Nếu bạn muốn tránh nó, bạn phải loại bỏ gợi ý.BẢNG HƯỚNG DẪN :

Nếu tồn tại một chỉ mục cụm, INDEX (0) buộc quét chỉ mục cụm và INDEX (1) buộc quét hoặc tìm kiếm chỉ mục cụm. Nếu không có chỉ mục cụm nào tồn tại, INDEX (0) buộc quét bảng và INDEX (1) được hiểu là lỗi.

Bạn cũng có thể thử tạo một chỉ mục không bao gồm trên WorkRequestId và bao gồm các cột createdDate và Notes bằng mệnh đề INCLUDE - lưu ý rằng điều này có thể có tác động tiêu cực đến hiệu suất chèn và kích thước của bảng.

Đối với những gì có giá trị, tên cơ sở dữ liệu mã hóa cứng trong các truy vấn làm cho mã cực kỳ khó di chuyển đến các môi trường thử nghiệm, trừ khi bạn có thể đủ khả năng cơ sở dữ liệu duy nhất cho mỗi phiên bản máy chủ.

— Piotr Rodak
nguồn