Není to tak docela odpověď, ale podělím se o svou zkušenost.
Když jsem se vrátil k Developer DBA poté, co jsem se přestěhoval do převážně prod DBA práce, trvalo to několik let sniffování parametrů SQL Serveru. Pochopil jsem více o enginu, jak funguje SQL, co je nejlepší nechat na klientovi atd., a byl jsem lepším kodérem SQL.
Například dynamické SQL nebo CURSORy nebo prostě špatný kód SQL pravděpodobně nikdy neutrpí sniffování parametrů. Ale lépe nastavit programování nebo jak se vyhnout dynamickému SQL nebo elegantnějšímu SQL pravděpodobně ano.
Všiml jsem si toho u složitého vyhledávacího kódu (spousta podmínek) a složitých sestav, kde výchozí nastavení parametrů ovlivnilo plán. Když vidím, jak by tento kód napsali méně zkušení vývojáři, pak neutrpí sniffování parametrů.
V každém případě dávám přednost maskování parametrů před WITH RECOMPILE. Aktualizace statistik nebo indexů si stejně vynutí rekompilaci. Ale proč pořád rekompilovat? Odpověděl jsem jinde na jednu z vašich otázek odkazem, který uvádí, že parametry jsou sniffovány během kompilace, takže v to také nevěřím.
Maskování parametrů je režie, to ano, ale umožňuje optimalizátoru vyhodnotit dotaz případ od případu, spíše než plošnou rekompilaci. Zejména s rekompilací SQL Server 2005 na úrovni příkazů
Také se zdá, že OPTIMALIZACE PRO NEZNÁMÉ v SQL Server 2008 dělá přesně to samé jako maskování. S mým kolegou SQL Server MVP jsme strávili nějaký čas zkoumáním a dospěli jsme k tomuto závěru.