Niezupełnie odpowiedź, ale podzielę się moim doświadczeniem.
Wąchanie parametrów zajęło kilka lat SQL Server, aby mnie ugryźć, kiedy wróciłem do Developer DBA po przejściu głównie do pracy prod DBA. Zrozumiałem więcej o silniku, jak działa SQL, co najlepiej pozostawić klientowi itp. i byłem lepszym programistą SQL.
Na przykład dynamiczny SQL lub kursory lub po prostu zły kod SQL prawdopodobnie nigdy nie będą podlegać podsłuchiwaniu parametrów. Ale lepiej ustawić programowanie lub jak uniknąć dynamicznego SQL lub bardziej eleganckiego SQL, najprawdopodobniej będzie.
Zauważyłem to dla złożonego kodu wyszukiwania (mnóstwo warunków) i złożonych raportów, w których domyślne parametry wpłynęły na plan. Kiedy zobaczę, jak mniej doświadczeni programiści napisaliby ten kod, nie będzie on cierpiał na podsłuchiwanie parametrów.
W każdym razie wolę maskowanie parametrów niż WITH RECOMPILE. Aktualizacja statystyk lub indeksów i tak wymusza ponowną kompilację. Ale po co cały czas rekompilować? Odpowiedziałem gdzie indziej na jedno z twoich pytań z linkiem, który wspomina, że parametry są wykrywane podczas kompilacji, więc też w to nie wierzę.
Tak, maskowanie parametrów jest narzutem, ale pozwala optymalizatorowi na ocenę każdego przypadku z osobna, a nie na całkowitą ponowną kompilację. Zwłaszcza w przypadku rekompilacji SQL Server 2005 na poziomie instrukcji
OPTYMALIZUJ NA NIEZNANE w SQL Server 2008 również wydaje się robić dokładnie to samo, co maskowanie. Mój kolega SQL Server MVP i ja spędziliśmy trochę czasu na badaniu i doszliśmy do tego wniosku.
