Nghi phạm thông thường:
- các hằng số trong adhoc, các tham số trong mã
- sự không phù hợp của các loại dữ liệu trong mã
- thông số đánh hơi
Điểm 1: trình tối ưu hóa có thể chọn kế hoạch tốt nhất cho các hằng số.
Thay đổi hằng số = thay đổi kế hoạch. Một plen tham số là đáng tin cậy
Điểm 2 sẽ giới thiệu các chuyển đổi ngầm định vì ưu tiên kiểu dữ liệu,
ví dụ cột varchar so với tham số nvarchar
Điểm 3: sử dụng mặt nạ tham số hoặc TỐI ƯU HÓA CHO UNKNOWN
Chỉnh sửa: Để kiểm tra: chạy Proc đã lưu, chạy sp_updatestats, chạy lại. Điều này sẽ làm mất hiệu lực các gói được lưu trong bộ nhớ cache tốt hơn sau đó xóa bộ nhớ cache của gói
Chỉnh sửa: sau bình luận của jcolebrand
Bạn có thể vô hiệu hóa việc đánh hơi một số cách. 3 chính là
- KIẾN NGHỊ. Đây là IMO ngớ ngẩn.
- TỐI ƯU (sic) CHO UNKNOWN
- Mặt nạ tham số
Mặt nạ tham số:
DECLARE @MaskedParam varchar(10)
SELECT @MaskedParam = @SignaureParam
SELECT...WHERE column = @MaskedParam
Mặt nạ và gợi ý TỐI ƯU có cùng tác dụng (có thể vì những lý do khác nhau). Nghĩa là, trình tối ưu hóa phải sử dụng số liệu thống kê và phân phối dữ liệu ( Lưu ý: vẫn đang được Mark Storey-Smith kiểm tra ) đánh giá các tham số trên giá trị riêng của chúng ? , hơn là những gì họ đã gọi lần cuối. Trình tối ưu hóa có thể biên dịch lại hay không. SQL Server 2005 đã thêm biên dịch lại mức câu lệnh để có ít tác động hơn
Bây giờ, tại sao một kế hoạch với các tham số "đánh hơi" là "dính" so với các tham số đeo mặt nạ / "không xác định", tôi không chắc chắn.
Tôi đã sử dụng mặt nạ tham số kể từ SQL Server 2000 cho tất cả trừ mã đơn giản nhất. Tôi đã lưu ý rằng nó có thể xảy ra với mã phức tạp hơn. Và tại công việc cũ của tôi, tôi có một số procs báo cáo rằng tôi có thể thay đổi mặc định tham số kế hoạch. Tôi cho rằng phương pháp "sùng bái hàng hóa" dễ dàng hơn một cuộc gọi hỗ trợ.
Chỉnh sửa 2, ngày 12 tháng 10 năm 2011, sau khi trò chuyện
Mặt nạ tham số và TỐI ƯU HÓA CHO UNKNOWN có tác dụng tương tự như tôi có thể nói
Gợi ý sạch hơn mặt nạ nhưng đã được thêm vào với SQL Server 2008.
Thông số đánh hơi xảy ra tại thời gian biên dịch.
VỚI RECOMPILE tạo ra một kế hoạch mới mỗi lần thực hiện. Điều này có nghĩa là sự lựa chọn mặc định kém sẽ ảnh hưởng đến kế hoạch. Ở công việc cuối cùng của tôi, tôi có thể chứng minh điều này một cách dễ dàng với một số mã báo cáo: thay đổi mặc định tham số đã thay đổi kế hoạch bất kể tham số được cung cấp.
Bài viết MS Connect này rất thú vị: Sử dụng chỉ mục dưới mức tối ưu trong quy trình được lưu trữ (được đề cập trong một trong các câu trả lời SO bên dưới)
- Bob Beauchemin cũng đề cập đến nó
Vấn đề nổi bật
Liệu đánh hơi vẫn áp dụng với VỚI RECOMPILE? Đó là, nếu trình tối ưu hóa biết loại bỏ kế hoạch, nó có nhằm mục đích tái sử dụng không?
Tại sao các kế hoạch đánh hơi "dính"?
Liên kết từ SO:
WHEREmệnh đề của nó ?