Не съвсем отговор, но ще споделя опита си.
Снифирането на параметри отне няколко години SQL Server, за да дойде и да ме ухапе, когато се върнах към Developer DBA, след като се преместих към предимно прод DBA работа. Разбрах повече за двигателя, как работи SQL, какво е най-добре да оставим на клиента и т.н. и бях по-добър кодер на SQL.
Например, динамичен SQL или CURSORs или просто лош SQL код вероятно никога няма да страдат от надушване на параметри. Но е по-вероятно да се направи по-добро програмиране или как да се избегне динамичен SQL или по-елегантен SQL.
Забелязах го за сложен код за търсене (много условни изрази) и сложни отчети, където параметрите по подразбиране засягат плана. Когато видя как по-малко опитни разработчици биха написали този код, тогава той няма да страда от надушване на параметри.
Във всеки случай предпочитам маскиране на параметри пред WITH RECOMPILE. Актуализирането на статистика или индекси принуждава прекомпилиране така или иначе. Но защо да прекомпилирам през цялото време? Отговорих другаде на един от вашите въпроси с връзка, която споменава, че параметрите се надушват по време на компилация, така че и аз не вярвам в това.
Маскирането на параметри е излишно, да, но позволява на оптимизатора да оценява заявката за случай по случай, вместо да прекомпилира цялостно. Особено при повторно компилиране на ниво израз на SQL Server 2005
OPTIMIZE FOR UNKNOWN в SQL Server 2008 също изглежда прави точно същото като маскирането. Моят колега за SQL Server MVP и аз прекарахме известно време в проучване и стигнахме до това заключение.
