Ikke helt et svar, men jeg deler min erfaring.
Parameter-sniffing tog et par år med SQL Server at komme og bide mig, da jeg gik tilbage til Developer DBA efter at have flyttet væk til for det meste prod DBA-arbejde. Jeg forstod mere om motoren, hvordan SQL fungerer, hvad der bedst var overladt til klienten osv., og jeg var en bedre SQL-koder.
For eksempel vil dynamisk SQL eller CURSOR'er eller bare almindelig dårlig SQL-kode sandsynligvis aldrig blive ramt af parametersniffing. Men bedre indstille programmering eller hvordan man undgår dynamisk SQL eller mere elegant SQL mere sandsynligt vil.
Jeg bemærkede det for kompleks søgekode (masser af betingelser) og komplekse rapporter, hvor parameterstandarder påvirkede planen. Når jeg ser, hvordan mindre erfarne udviklere ville skrive denne kode, vil den ikke lide parametersniffing.
Under alle omstændigheder foretrækker jeg parametermaskering frem for WITH RECOMPILE. Opdatering af statistik eller indekser fremtvinger en omkompilering alligevel. Men hvorfor rekompilere hele tiden? Jeg har svaret andetsteds på et af dine spørgsmål med et link, der nævner, at parametre sniffes under kompilering, så jeg har heller ikke tiltro til det.
Parametermaskering er en overhead, ja, men den giver optimeringsværktøjet mulighed for at evaluere forespørgslen fra sag til sag, snarere end generel rekompilering. Især med sætningsniveau rekompilering af SQL Server 2005
OPTIMER TIL UKENDT i SQL Server 2008 ser også ud til at gøre nøjagtig det samme som maskering. Min SQL Server MVP-kollega og jeg brugte noget tid på at undersøge og nåede frem til denne konklusion.