1

I would like to find out if using OPTION(RECOMPILE) is beneficial when executing dynamic sql queries?

There are a few points to keep in mind:

  1. There will be hundreds (maybe even thousands) of different dynamic queries created.
  2. About 1/4 of them will be used repeatedly with "higher-frequency". Let's say several hundred times a day (that's several hundred executions of 1 specific query per day).
  3. The rest will be used sporadically, might be a few times per day, might be a few times over a week.
  4. Even if a query should be "composed" basically the same way (ie. joining the same tables etc.) as the one before it. There is also the question of input variables that come into play.
  5. At minimum 2 objects (tables, views, joins etc.) will come into play in every query. At most it will be dozens of objects, in average it should be around 10 (this should loosely corelate with the 1/4 "high-frequency" queries)
  6. Purpose is to optimize for speed.

Thank you beforehand for any tips and recommendations.

DB used: MS SQL 2019

1 Answer 1

1

No.

Now that I got that out of the way, 🙂, there's no need to use query hints until there is a need to use them. In other words, don't proactively use them, only reactively use them after you've measurably determined your query's use case will benefit from them.

Now to the specifics. OPTION (RECOMPILE) (and RECOMPILE hints) is useful in edge case parameter sniffing issues where there's no alternative fix, as discussed in this Kendra Little article. Until you determine you have an otherwise unsolvable parameter sniffing issue with your Dynamic SQL, then there's no need to use the OPTION (RECOMPILE) query hint. In fact it'll only slow your queries down, possibly by an insignificant amount of time, but perhaps not when you have the same query recompiling over and over at a high frequency.

The reason SQL Server caches query plans is to reduce latency on repeated runs of the same query, when possible, by not having to recompile and re-decide on what execution plan to use to serve your queries. Also your Dynamic SQL will already elicit a recompile every time any change is made to it from the last time it ran or when it's no longer in the plan cache, as cached query plans are only re-usable by the same exact query (even a comment change will generate a new plan) since the query text is hashed as the key to the cached plan.

All of that being said, I just want to reiterate that query hints are not necessarily bad, and don't let my hard no above scare you away. It's just that query hints are meant to be used in more edge case scenarios, not your normal use cases, and improper use of them can actually severely impact performance. OPTION (RECOMPILE) is a good tool to keep in the back of your mind for when you're in a parameter sniffing performance jam as a temporary quick fix, or when there's an actual valid case to use it. But I would definitely not recommend just using it without the testing to back it up, and there's nothing special about Dynamic SQL that automatically makes sense to use RECOMPILE hints with it.

2
  • 1
    Thank you for your quick response (again) :o) What you wrote makes sense. Particularly helpful for me is the mention about Dynamic SQL eliciting a recompile every time any change is made. I was not absolutely sure about the way variables comes into play when the engine decides/prepares EP, but the information about query text is hashed sorts this out pretty clearly. I'l try to backup your claims by some test runs and write a short summary after. Thanks for your help and have a good day.
    – Jan Martin
    Mar 16, 2021 at 6:54
  • @JanMartin For sure, no problem! 🙂 Best of luck!
    – J.D.
    Mar 16, 2021 at 11:19

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.