硬编码或魔术文字可以提高SQL Server存储过程的性能？

Question

From day 1 of my programming career I have always been told hard-coding/magic numbers or literals are bad. One should avoid it. I followed this principle even in Stored Procedures in SQL Server.

Recently I came across this article by Ian Jose and it came as a rude shock to me. He has nicely explained the problem with this practice in SQL Server Stored Procedures with evidence. Ian has demonstrated that the performance takes a big hit with this approach.

See this article by Chris Hedgate to know what my reaction was when I read Ian's blog.

I understand if it is a smaller code snippet and the hard coded value is not used more than once, then some people take the liberty keeping them instead of declaring them as variables or constants and using the variables or constants instead. But it seems hard coding should be encouraged in Stored Procedures?

I did find a similar discussion on SO but that thread isn't evaluating the performance hit, rather it is talking about how to avoid hard-coding, something that even I used to consider myself very good at. But now after reading Ian's blog, I feel I am adding more problem there than solving it.

I would like to request the other experts to share their experience on this topic as this seems to be a violation of fundamental programming guidelines. Could this be because of the way SQL Server is designed? Is this not an issue in Oracle or MySQL? Oracle in fact suggest these 3 nice approaches to avoid hard coding.

Edit: Thank you all for your valuable comments. I would like to request for some more statistics, to constructively challenge Ian's numbers. Just to conclude that avoiding hard coding does not have that bad an impact on performance, which is what Ian has demonstrated. I am sorry if I am asking for too much and eagerly look forward to your responses.

I had also opened a thread on LinkedIn as I didn't get many responses here at first. For people who have the same confusion as me can refer to that for some more info.

Answer 1

Here's how I understand the problem:

1. Hard coded literals in a DBMS (SQL / Oracle) do improve performance.
2. However, the second time you execute the query, where the hard coded literal changes, it must be recompiled, which fills up the cache.
3. This means that the cache can't be used efficiently for the rest of the DB.

So, whilst:

SELECT * FROM X WHERE Y = '123'

Might be slightly faster than:

SELECT * FROM X WHERE Y = @myVar

If you then want to do:

SELECT * FROM X WHERE Y = '234'

The DBMS sees that as a different query . This then fills up the cache, meaning that the next time you issue a query that should be cached, it will be slower.

Answer 2

Parameters are better, since the same plan can be used for multiple parameter values. An SP in SQL Server is a contract with the app writer that one plan can be used for multiple invocations. It has been eight years since I worked in SQL Server, and much may have changed. However, the optimizer will "sniff" the parm value for optimization purposes. It is nice if that value is "typical". Unfortunately, recompile can happen at any time, and hence with any parameter value. Plan guides are one technique to make an application immune to this danger. There are likely other techniques as well.