5

I routinely "scrub" the parameters of my stored procedures at the top before I run the query like this:

-- Scrub params
SET @SearchText = NULLIF(@SearchText, '')
SET @ThreadId = NULLIF(@ThreadId, 0)
SET @Hashtag = NULLIF(@Hashtag, '')

But then from this article I read the following:

If the query predicate uses a local variable, consider rewriting the query to use a parameter instead of a local variable. The value of a local variable is not known when the Query Optimizer creates the query execution plan. When a query uses a parameter, the Query Optimizer uses the cardinality estimate for the first actual parameter value that is passed to the stored procedure.

Does it count as using a local variable if the value originated from a parameter? I'm wondering if my parameter scrubbing could affect the creation of the query execution plan.

2 Answers 2

6

Does it count as using a local variable if the value originated from a parameter?

No, SQL Server will still see the reference as a parameter, which may be sniffed.

"Parameter sniffing" refers to a process whereby SQL Server's execution environment "sniffs" the current parameter values during compilation or recompilation, and passes it along to the query optimizer so that they can be used to generate potentially faster query execution plans. The word "current" refers to the parameter values present in the statement call that caused a compilation or a recompilation. Both in SQL Server 2000 and SQL Server 2005, parameter values are sniffed during compilation or recompilation for the following types of batches:

  • Stored procedures
  • Queries submitted via sp_executesql
  • Prepared queries

Generally, the plan for the whole procedure is compiled (and parameters sniffed) before execution begins, so your SET will not have executed when the sniffing occurs. An exception may occur if the statement is recompiled for any reason after the procedure starts executing. In that case, the recompilation process will see the new value you have set.

In most cases, each statement referencing a parameter will be optimized based on the sniffed value, not any changes you have made within the procedure.

Further reading: Parameter Sniffing, Embedding, and the RECOMPILE Options

2
  • Wait, I'm a little confused. So changing the parameter values doesn't change which values are sniffed and passed to the query optimizer, but if the value that it changes to is very different than the sniffed value, wouldn't that mean that the query optimizer could choose a sub-optimal plan due to using the sniffed values versus the runtime values and, therefore, scrubbing parameters may actually harm performance?
    – adam0101
    Commented Sep 2, 2020 at 17:31
  • @adam0101 Yes that's right. The optimizer will usually choose a plan based on the sniffed value. If you change that to something very different, the plan might be suboptimal. But OTOH the point of stored procedures is that one plan ought to work well for many.
    – Paul White
    Commented Sep 2, 2020 at 17:41
2

It does affect the cardinality estimator if you use a different variable and set it using your parameter.

If you use the parameter directly, then it won't affect the cardinality estimator.

I did a quick test on the stackoverflow datbase and if you look at this, you will notice that when you use local variable, the estimated number of row is different then, but the same as when you set the parameter with himself.

enter image description here

2
  • But I'm not declaring a local variable, I'm overwriting the parameter with a new value before the query. Do you get the same result if you set @location = NULLIF(@location, '')?
    – adam0101
    Commented Sep 2, 2020 at 15:55
  • yes, just noticed it and added to the answer. Paul White was right, in this case it won't affect the cardinality estimator Commented Sep 2, 2020 at 15:58

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.