Tư vấn về chẩn đoán truy vấn chậm đôi khi

Tôi có một quy trình được lưu trữ trả về kết quả từ chế độ xem được lập chỉ mục thông qua chỉ mục bao phủ. Thông thường, nó chạy nhanh (~ 10ms), đôi khi nó có thể chạy tới 8 giây.

Đây là một ví dụ thực thi ngẫu nhiên (lưu ý: đây không phải là một cách chậm, nhưng văn bản truy vấn giống với giá trị được truyền qua):

declare @p2 dbo.IdentityType
insert into @p2 values(5710955)
insert into @p2 values(5710896)
insert into @p2 values(5710678)
insert into @p2 values(5710871)
insert into @p2 values(5711103)
insert into @p2 values(6215197)
insert into @p2 values(5710780)

exec ListingSearch_ByLocationAndStatus @statusType=1,@locationIds=@p2

Đây là XUÂN:

ALTER PROCEDURE [dbo].[ListingSearch_ByLocationAndStatus]
    @LocationIds IdentityType READONLY,
    @StatusType TINYINT
AS
BEGIN
    SET NOCOUNT ON;

    SELECT      -- lots of fields
    FROM        [dbo].[ListingSearchView][a] WITH (NOEXPAND)
    INNER JOIN  @LocationIds [b] ON [a].[LocationId] = [b].[Id]
    WHERE       [a].[StatusType] = @statusType
    OPTION (RECOMPILE);

(lưu ý: tôi đã thêm OPTION (RECOMPILE)gợi ý gần đây sau một số lời khuyên, nhưng nó không giúp được gì.

Đây là chỉ mục bao phủ (lưu ý: chế độ xem cũng có một chỉ mục được nhóm ListingId, là duy nhất)

CREATE NONCLUSTERED INDEX [IX_ListingSearchView_ForAPI] ON [dbo].[ListingSearchView]
(
    [LocationId] ASC,
    [StatusType] ASC
)
INCLUDE ( -- all the fields in the query) WITH (PAD_INDEX = OFF, STATISTICS_NORECOMPUTE = OFF, SORT_IN_TEMPDB = OFF, DROP_EXISTING = OFF, ONLINE = OFF, ALLOW_ROW_LOCKS = ON, ALLOW_PAGE_LOCKS = ON)
GO

Tôi đặt một dấu vết hồ sơ, với số liệu thống kê XML về kế hoạch.

Đây là một tốc độ chậm (6 giây) và kế hoạch có liên quan:

Trông giống hệt như tôi mong đợi và là cùng một kế hoạch khi truy vấn nhanh.

Đây là phần phóng to của phần tốn kém của kế hoạch, nếu điều đó giúp:

Dưới đây là lược đồ đầy đủ của các bảng xem / sao lưu, nếu điều đó giúp: https://pastebin.com/wh1sRcbQ

Ghi chú:

• Các chỉ mục đã được phân mảnh, thống kê cập nhật.
• Ban đầu truy vấn là nội tuyến chống lại chế độ xem, nhưng tôi đã chuyển sang XUÂN để thử và giúp ổn định. Không giúp được gì.
• Thêm WITH OPTION (RECOMPILE);gợi ý (không hoạt động, vì vậy không thể đánh hơi thông số?)
• Các truy vấn khác trong hệ thống đôi khi cũng chạy chậm và chúng cũng không có vấn đề rõ ràng trong kế hoạch của chúng.
• Có thể bị khóa? Không chắc chắn làm thế nào để xác nhận.

Bất kỳ ý tưởng về những gì tôi có thể thử tiếp theo?

Cảm ơn

Tôi thực sự không nghĩ sử dụng OPTION (RECOMPILE)là một cách hiệu quả để loại bỏ khả năng đánh hơi thông số.

Việc đánh hơi tham số xảy ra khi SQL nhầm lẫn về một truy vấn cụ thể và nghĩ rằng nó mới vì nó thấy các tham số mới. Nó chậm vì mất thêm thời gian để tạo kế hoạch thực hiện mới.

Tất cả các tùy chọn đó là buộc SQL phải tạo ra một kế hoạch mới mỗi lần tương tự như vậy. Thay vào đó, bạn có thể muốn xem xét thêm các tham số mặc định bằng gợi ý này:

OPTION(OPTIMIZE FOR(@LocationIds='xx',@StatusType='xx'))

Khi chọn tham số cho mặc định, đảm bảo sử dụng bộ đại diện thống kê.
Điều đó sẽ buộc cùng một kế hoạch được sử dụng mỗi lần và loại bỏ khả năng đánh hơi tham số. Khi bạn làm điều đó và xác định rằng nó không có ích, thì có thể an toàn để loại bỏ tham số đánh hơi như một khả năng.

Có lẽ cố gắng để buộc thứ tự, vì vậy bạn có thể luôn luôn bắt đầu với bảng nhỏ hơn (biến). Điều đó gây khó khăn với các lượt xem mặc dù ...

    SELECT  -- lots of fields
    FROM    @LocationIds [b] WITH (NOEXPAND)
            INNER JOIN  [dbo].[ListingSearchView][a] WITH (NOEXPAND) 
                ON [a].[LocationId] = [b].[Id]
    WHERE   [a].[StatusType] = @statusType
    OPTION (FORCE ORDER);

hoặc bạn có thể buộc tham gia vòng lặp nếu đó thường là cách bạn muốn tham gia biến bảng vào chế độ xem, điều này cũng sẽ buộc thứ tự ...

    SELECT  -- lots of fields
    FROM    @LocationIds [b] WITH (NOEXPAND)
            INNER LOOP JOIN  [dbo].[ListingSearchView][a] WITH (NOEXPAND) 
                ON [a].[LocationId] = [b].[Id]
    WHERE   [a].[StatusType] = @statusType
    --leaving this here so you don't get an annoying warning 
    OPTION (FORCE ORDER);

Viết tên của thủ tục Store trong Trình soạn thảo truy vấn, sau đó chọn Cửa hàng Proc. tên và sau đó Chọn kế hoạch Thực hiện Ước tính Hiển thị hoặc Nhấp (Ctrl + L). bên dưới hình ảnh này.

sau đó các gói Thực thi hiển thị ngay bên cạnh Tab Tin nhắn ở cuối Trình soạn thảo truy vấn. sau đó trong các dòng màu xanh lá cây hiển thị các chi tiết Index bị thiếu và nhấp chuột phải vào đó. Sau đó, truy vấn mới mở trong tab mới, sau đó tạo INDEX. sau đó Truy vấn của bạn chạy nhanh.

Vì vậy, tôi đã sử dụng phương pháp này để Chẩn đoán Truy vấn người làm việc chậm. và cũng có rất nhiều truy vấn hoặc phương pháp mà bạn có thể sử dụng.

Nếu bạn nghĩ rằng vấn đề nằm ở việc chặn, tôi sẽ đề nghị bạn sử dụng mức cô lập giao dịch lạc quan Đọc Ảnh chụp được cam kết (lưu ý rằng điều này sẽ đặt chi phí trên tempDB của bạn).

TÀI LIỆU THAM KHẢO: https://docs.microsoft.com/en-us/dotnet/framework/data/adonet/sql/snapshot-isolation-in-sql-server

Vấn đề không nằm ở việc chặn đọc / ghi, bạn có thể thử thêm chỉ mục vào chế độ xem của mình (sự lựa chọn tốt nhất về chỉ mục phụ thuộc vào tính chọn lọc của dữ liệu của bạn)

CREATE NONCLUSTERED INDEX IX_ListingSearchView (LocationID, StatusType) INCLUDE (other columns...)