Non proprio una risposta, ma condividerò la mia esperienza.
Lo sniffing dei parametri ha richiesto alcuni anni di SQL Server per venire a mordermi, quando sono tornato al DBA per sviluppatori dopo essere passato al lavoro principalmente DBA di prod. Ho capito di più sul motore, su come funziona SQL, cosa era meglio lasciare al client ecc. ed ero un programmatore SQL migliore.
Ad esempio, SQL dinamico o CURSOR o semplicemente codice SQL errato probabilmente non subiranno mai lo sniffing dei parametri. Ma è più probabile che sia meglio impostare la programmazione o come evitare SQL dinamico o SQL più elegante.
L'ho notato per codice di ricerca complesso (molti condizionali) e report complessi in cui le impostazioni predefinite dei parametri hanno influenzato il piano. Quando vedo come gli sviluppatori meno esperti scriverebbero questo codice, non subirà lo sniffing dei parametri.
In ogni caso, preferisco il mascheramento dei parametri a WITH RECOMPILE. L'aggiornamento di statistiche o indici forza comunque una ricompilazione. Ma perché ricompilare tutto il tempo? Ho risposto altrove a una delle tue domande con un link che menziona che i parametri sono stati annusati durante la compilazione, quindi non ci credo nemmeno io.
Il mascheramento dei parametri è un sovraccarico, sì, ma consente all'ottimizzatore di valutare la query caso per caso, anziché la ricompilazione generale. Soprattutto con la ricompilazione a livello di istruzioni di SQL Server 2005
OTTIMIZZA PER SCONOSCIUTO in SQL Server 2008 sembra fare esattamente la stessa cosa del mascheramento. Io e il mio collega MVP di SQL Server abbiamo trascorso un po' di tempo a indagare e siamo giunti a questa conclusione.
