Should you always anticipate problems caused by parameter sniffing?

Question

Using sql server 2008, I have a simple stored procedure, the contents of which are

DELETE FROM [ABC].[dbo].[LookUpPermissions] 
WHERE Code = @Code

In a recent code review, the DBA said I should "add parameter sniffing" which I believe means I should account for parameter sniffing. I've never done this in the past and I am not having any performance issues with the query so I would think it is unnecessary.

While I presume the answer may be user preference, would it be best practice to account for parameter sniffing? Is it necessary if the stored procedure is called on a small dataset, used infrequently and is having no performance issues?

---

edit
Is this only applicable to parameters used in a WHERE clause, or for example, would you possibly need to account for all parameters in an INSERT statement?

Answer 1

A simple search for a single value like this shouldn't be vulnerable to parameter sniffing. It's more of a concern when the parameters passed in result in widely different results and the optimal execution plan varies from the one that has been previously produced.

As an example, think of a query that looks for rows where a date column is between a @start_date and an @end_date. Calling the procedure with a date range of 2 days may produce/cache an execution plan that is not optimal for a date range of 1 year.

Answer 2

Parameter Sniffing is another built-in "smarty thingy" (remember inline spell/grammar cheking) that Microsoft uses to optimize SQL queries. By sniffing the input parameters SQL Server makes it's best educated guess about which cached query plan would be the best plan to use. It does not always make the correct choice.

Read this for information on how to trick SQL into not using pramater sniffing.