Of cousre, with OPTION RECOMPILE, you also have to weigh the CPU cost of continuously recompiling execution plans versus the cost of a poor, but not awful, execution plan.

Thanks for adding the link to Itzik’s article about recompiling select queries, it makes for great background info to add to anyone’s performance tuning toolkit. It’s not as much of a black art as people make it out to be, it just requires some careful thought, a solid methodology, and (on occasion) digging into the nasty guts of the execution plan.

As far as index hinting goes, it’s usually something I save for the end of query tuning, but I always consider it an option. In the current application I’m working on, all database activity is controlled through stored procedures and some of the procedures have up to 12 parameters. Certain combinations of parameters produce different join paths. In cases like that providing the query engine with as much information up front is key to getting the queries to perform adequately. In one scenario, I was able to tune the execution of the query from 4 minutes and 28 seconds to 6 seconds by carefully apply indexes (I avoided plan caches by constantly generating new GUIDs and putting random spaces in my ad hoc SQL, which works to avoid cached plans for the moment).

Also for parameter sniffing, the recompile hint is another good option. If the parameters can be vastly different or refer to data with big cardinality differences than perhaps the recompile hint can be your friend here as well. The local parameters option sort of has a similar effect and can also work.

Great post again because it shows those two important pieces of writing well performing code: 1.) Using common sense and a careful methodology and 2.) You are actually looking at your code and looking at query plans and using empirical evidence with changes!

Sometimes just getting folks to look at query plans can be a big battle