No es exactamente una respuesta, pero compartiré mi experiencia.
El rastreo de parámetros tomó algunos años de SQL Server para venir y morderme, cuando volví a Developer DBA después de mudarme para trabajar principalmente como DBA de producción. Entendí más sobre el motor, cómo funciona SQL, qué era mejor dejar al cliente, etc. y era un mejor programador de SQL.
Por ejemplo, SQL dinámico o CURSOR o simplemente un código SQL incorrecto probablemente nunca sufra el rastreo de parámetros. Pero es mejor configurar la programación o cómo evitar SQL dinámico o SQL más elegante.
Lo noté para el código de búsqueda complejo (muchos condicionales) y los informes complejos donde los valores predeterminados de los parámetros afectaron el plan. Cuando vea cómo los desarrolladores menos experimentados escribirían este código, entonces no sufrirá la detección de parámetros.
En cualquier caso, prefiero enmascarar parámetros a CON RECOMPILE. La actualización de estadísticas o índices obliga a una recompilación de todos modos. Pero, ¿por qué recompilar todo el tiempo? He respondido en otra parte a una de sus preguntas con un enlace que menciona que los parámetros se detectan durante la compilación, por lo que tampoco tengo fe en eso.
El enmascaramiento de parámetros es una sobrecarga, sí, pero permite que el optimizador evalúe la consulta caso por caso, en lugar de una recompilación general. Especialmente con la recopilación de nivel de declaración de SQL Server 2005
OPTIMIZE FOR UNKNOWN en SQL Server 2008 también parece hacer exactamente lo mismo que enmascarar. Mi colega MVP de SQL Server y yo dedicamos un tiempo a investigar y llegamos a esta conclusión.
