Nicht ganz eine Antwort, aber ich werde meine Erfahrung teilen.
Das Parameter-Sniffing brauchte einige Jahre SQL Server, um mich zu beißen, als ich zurück zum Entwickler-DBA ging, nachdem ich hauptsächlich zur prod-DBA-Arbeit gewechselt war. Ich verstand mehr über die Engine, wie SQL funktioniert, was am besten dem Client überlassen wurde usw. und ich war ein besserer SQL-Programmierer.
Zum Beispiel werden dynamisches SQL oder CURSORs oder einfach nur schlechter SQL-Code wahrscheinlich nie Parameter-Sniffing erleiden. Aber besser eingestellte Programmierung oder wie man dynamisches SQL vermeidet oder eleganteres SQL wird es wahrscheinlicher.
Ich bemerkte es bei komplexem Suchcode (viele Bedingungen) und komplexen Berichten, bei denen Parametervorgaben den Plan beeinflussten. Wenn ich sehe, wie weniger erfahrene Entwickler diesen Code schreiben würden, dann wird er nicht unter Parameter-Sniffing leiden.
Auf jeden Fall bevorzuge ich die Parametermaskierung gegenüber WITH RECOMPILE. Das Aktualisieren von Statistiken oder Indizes erzwingt sowieso eine Neukompilierung. Aber warum immer neu kompilieren? Ich habe an anderer Stelle auf eine Ihrer Fragen mit einem Link geantwortet, der erwähnt, dass Parameter während der Kompilierung geschnüffelt werden, also glaube ich auch nicht daran.
Das Maskieren von Parametern ist ein Overhead, ja, aber es ermöglicht dem Optimierer, die Abfrage von Fall zu Fall zu bewerten, anstatt sie pauschal neu zu kompilieren. Besonders bei der Neukompilierung von SQL Server 2005 auf Anweisungsebene
OPTIMIZE FOR UNKNOWN in SQL Server 2008 scheint auch genau dasselbe zu tun wie Maskierung. Mein SQL Server MVP-Kollege und ich haben einige Zeit nachgeforscht und sind zu diesem Schluss gekommen.
