Không hẳn là một câu trả lời, nhưng tôi sẽ chia sẻ kinh nghiệm của mình.
Việc đánh hơi tham số phải mất một vài năm SQL Server mới đến với tôi, khi tôi quay trở lại DBA dành cho nhà phát triển sau khi chuyển sang công việc chủ yếu là DBA. Tôi đã hiểu thêm về công cụ, cách SQL hoạt động, những gì tốt nhất để lại cho máy khách, v.v. và tôi là một lập trình viên SQL giỏi hơn.
Ví dụ:SQL động hoặc CURSORs hoặc chỉ là mã SQL xấu đơn giản có thể sẽ không bao giờ bị đánh hơi tham số. Nhưng thiết lập lập trình tốt hơn hoặc cách tránh SQL động hoặc SQL thanh lịch hơn sẽ có nhiều khả năng hơn.
Tôi nhận thấy nó đối với mã tìm kiếm phức tạp (nhiều điều kiện) và các báo cáo phức tạp trong đó các giá trị mặc định của tham số ảnh hưởng đến kế hoạch. Khi tôi thấy các nhà phát triển ít kinh nghiệm sẽ viết mã này như thế nào, thì nó sẽ không bị đánh hơi tham số.
Trong bất kỳ trường hợp nào, tôi thích che thông số thành WITH RECOMPILE. Việc cập nhật số liệu thống kê hoặc chỉ mục buộc phải biên dịch lại. Nhưng tại sao biên dịch lại mọi lúc? Tôi đã trả lời ở nơi khác cho một trong những câu hỏi của bạn với một liên kết đề cập đến các thông số được đánh giá trong quá trình biên dịch, vì vậy tôi cũng không tin vào nó.
Che thông số là một chi phí, có, nhưng nó cho phép trình tối ưu hóa đánh giá trường hợp truy vấn theo từng trường hợp, thay vì biên dịch lại hàng loạt. Đặc biệt với việc biên dịch lại mức câu lệnh của SQL Server 2005
OPTIMIZE FOR UNKNOWN trong SQL Server 2008 dường như cũng hoạt động giống hệt như tạo mặt nạ. Đồng nghiệp SQL Server MVP của tôi và tôi đã dành thời gian điều tra và đi đến kết luận này.
