Hiệu suất truy vấn kém

Chúng tôi có một quy trình lớn (10.000+ dòng) thường chạy trong 0,5-6,0 giây tùy thuộc vào lượng dữ liệu mà nó phải làm việc. Trong khoảng một tháng qua, nó đã bắt đầu mất hơn 30 giây sau khi chúng tôi cập nhật thống kê với FULLSCAN. Khi nó chậm lại, một sp_recompile "khắc phục" vấn đề, cho đến khi công việc thống kê hàng đêm chạy lại.

Bằng cách so sánh các kế hoạch thực hiện chậm và nhanh, tôi đã thu hẹp nó xuống một bảng / chỉ mục cụ thể. Khi nó chạy chậm, nó ước tính ~ 300 hàng sẽ được trả về từ một chỉ mục cụ thể, khi nó chạy nhanh, nó ước tính 1 hàng. Khi nó chạy chậm, nó sử dụng Bộ đệm bảng sau khi thực hiện tìm kiếm trên chỉ mục, khi nó chạy nhanh, nó không thực hiện Bộ đệm bảng.

Sử dụng DBSS SHOW_STATISTICS, tôi đã vẽ biểu đồ biểu đồ chỉ mục trong excel. Tôi thường mong đợi biểu đồ sẽ là "những ngọn đồi lăn" hơn, nhưng thay vào đó, nó trông giống như một ngọn núi, điểm cao nhất cao hơn 2x-3x so với hầu hết các giá trị khác trên biểu đồ.

Nếu tôi cập nhật số liệu thống kê về nó, mà không có FULLSCAN, nó trông bình thường hơn. Nếu sau đó tôi chạy nó với FULLSCAN thì có vẻ như tôi đã mô tả ở trên.

Điều này cảm thấy giống như một vấn đề đánh hơi tham số, và đặc biệt liên quan đến phân phối chỉ số kỳ lạ (dường như) ở trên.

Các Proc có trong một tham số có giá trị bảng, tham số đánh hơi có thể xảy ra trên một tham số có giá trị bảng?

EDIT: Proc cũng có 12 tham số khác, một số trong số đó là tùy chọn, hai trong số đó là ngày bắt đầu và ngày kết thúc.

Là biểu đồ lẻ, hay tôi đang sủa sai cây?

Tôi chắc chắn thoải mái khi cố gắng điều chỉnh truy vấn và / hoặc cố gắng điều chỉnh lập chỉ mục của mình. Nếu đó là bản sửa lỗi tuyệt vời, thì tại thời điểm đó, câu hỏi của tôi là về biểu đồ sai lệch.

Tôi nên đề cập rằng đây là một chỉ số cụm PK IDENTITY. Chúng tôi có hai hệ thống nói chuyện với nhau, một hệ thống kế thừa, một hệ thống trồng tại nhà mới. Cả hai hệ thống lưu trữ dữ liệu tương tự. Để giữ cho chúng đồng bộ hóa PK trên bảng này trong hệ thống mới được tăng lên khi mọi thứ được thêm vào hệ thống cũ, ngay cả khi dữ liệu không xuất hiện (đã hoàn tất việc xác định lại). Vì vậy, có thể có một số khoảng trống trong việc đánh số trong cột này. Hồ sơ hiếm khi, nếu có, bị xóa.

Bất kỳ suy nghĩ sẽ được đánh giá rất cao. Tôi hạnh phúc hơn để thu thập / bao gồm nhiều thông tin hơn.

Điều này cuối cùng có liên quan đến việc đánh hơi tham số. Nó đã xảy ra đến mức một số phiên bản hình thành kỳ lạ của truy vấn này đã được thực thi QUYỀN SAU các số liệu thống kê được xây dựng lại. Vì vậy, kế hoạch lưu trữ không đại diện cho phần lớn các cuộc gọi. Tôi đã sử dụng thủ thuật sao chép các tham số ngày vào các biến cục bộ và điều này chỉ hoạt động tốt, ít ảnh hưởng đến hiệu suất. Điều này không trả lời tại sao biểu đồ trông rất "tắt", nhưng nó giải thích các vấn đề về hiệu suất của tôi.