• Indianrock (12/9/2016)


    I've heard this advice everywhere. Don't do things to change the way the sql optimizer produces plans etc. "it's smart so don't use plan guides, query hints, force recompile etc etc etc etc"

    If you don't know what you are doing and don't understand the SQL Server query optimizer then this advice is pretty good. I would say, for example, that 90% of the WITH (NOLOCK) table hints I have seen are unnecessary, unhelpful and counter-intuitive.

    Query hints, the ability to force a recompile, etc exist for a reason. There are times when your careful, informed and extensive testing leads you to conclude that a overriding the optimizer's decisions is the way to go. Recently there are times that I have needed to require a stored proc to re-compile before each run, force a parallel execution plan (using Adam Machanic's make_parallel) or force a serial plan using OPTION (MAXDOP 1). Again, in each case for me, these changes occurred after extensive testing and with a full understanding of the risks.

    "I cant stress enough the importance of switching from a sequential files mindset to set-based thinking. After you make the switch, you can spend your time tuning and optimizing your queries instead of maintaining lengthy, poor-performing code."

    -- Itzik Ben-Gan 2001