Stored Procedure is slower than on the fly query - sql

Question

So I have this really simple SP GetData which has two parameters and looks like this
SET ANSI_NULLS ON
GO
SET QOUTED_IDENTIFIER ON
GO
CREATE PROCEDURE [dbo].[GetData]
#Id int = NULL,
#ExternalId nvarchar(500) = NULL
AS
BEGIN
SET NOCOUNT ON;
SELECT
t.Id,
t.ExternalId,
t.Column1 -- other columns ommited for brevity
FROM [SomeTable] t
WHERE
(t.Id = #Id OR #ID IS NULL) AND
(t.ExternalId = #ExternalId OR #ExternalId IS NULL)
END
It's very simple. Just one select statement from one table. Now, what I am concerned about is that If I execute this procedure the time it takes on average is 0.505369 seconds but if I extract that select query and execute it like that the query takes from 0.023923 seconds on average. I am really concerned about this because this procedure is called really really often and is one of the critical procedure in my application that's why it's so minimized for now the 0.5s is a bit acceptable. for this time the table contains just 4.95 million rows. There is a clustered index on Id column and a non-clustered index on ExternalId column. the table is supposed to increase to 45 million rows in coming weaks and than the data insertion rate will decrease. on 45 million rows I don't think that the SP shown above will give some reasonable times. I don't really understan what is the problem here, or is it supposed to be like that ? as I know after execution of SP the plan is cached and for the next time the plan is not re created so should it be faster than the on the fly query ? In this case is it better to use Ad hoc query in stead of the SP ? The DB is Sql Server 2012. Thanks in advance

Answer 1

My first suggestion would be to use the option "Recompile". What happens is that the queries are compiled the first time the stored procedure is run (this is called "parameter sniffing"). This might have an impact on performance, if the execution path for the first run is different from the optimal execution path. For instance, sometimes the stored procedure is tested on super small tables, so indexes do not get used.
The syntax is:
SELECT
t.Id,
t.ExternalId,
t.Column1 -- other columns omited for brevity
FROM [SomeTable] t
WHERE
(t.Id = #Id OR #ID IS NULL) AND
(t.ExternalId = #ExternalId OR #ExternalId IS NULL)
OPTION (recompile);
However, your query uses or in the where clause which makes it difficult for the optimizer to use indexes at all. One option is to switch to dynamic SQL, something like this:
declare #sql nvarchar(max) = '
SELECT t.Id, t.ExternalId,
t.Column1 -- other columns omited for brevity
FROM [SomeTable] t
WHERE 1=1 ';
set #sql = #sql + (case when #id is not null then ' and t.Id = #id'` else '' end) +
(case when #ExternalId is not null then ' and t.externalId = #externalId' else '' end);
exec sp_executesql #sql, N'#Id int, #ExternalId int', #id = #id, #externalId = #externalId;

Answer 2

There are a few factors which help determine the best course of action:
The distribution of data in the ExternalId column:
If ExternalId values are fairly evenly spread out, then outside of the possible NULL value not even using that field, one value should not produce a plan that would not work for other values. You don't need to worry about the Id field, assuming it is the PK, because the very nature of a PK is that there is only 1 per any value.
The actual variability of input parameter values:
How often is either one of them NULL, a particular value, or any value? Meaning, are 90% of the executions of this proc coming in with #Id of NULL and #ExternalId one of 5 different values? Or is it that 90% of the time a different #Id value is passed in? And/or is there 1 particular value of #ExternalId that is used or is it usually different?
First
Before considering any structural changes, please make sure that the datatype of the ExternalId field matches the datatype of the #ExternalId input parameter. The #ExternalId input param is defined as NVARCHAR(500), so if the ExternalId field is actually declared as VARCHAR, then you are probably getting an "Index Scan" instead of an "Index Seek" due to the implicit conversion from VARCHAR to NVARCHAR.
Options
Using OPTION (RECOMPILE): This has been mentioned already and I am including it both for the sake of completeness and to say that this should be your last resort. This option ensures that you don't get a bad cached plan by disallowing that you ever have any cached plans. Which means that you are also never able to benefit from plan caching. In most cases there are better choices.
AND, and this is very important in situations like yours where the stored procedure is executed frequently: the reason that execution plans are cached is due to the expense of figuring them out, hence telling SQL Server to figure it out again and again, for every execution, will take its toll on the process.
Using OPTION (OPTIMIZE FOR...): This option allows you to tell the Query Optimizer to assume an average distribution, based on current statistics, for all input parameters (when using OPTIMIZE FOR UKNOWN) or assume a distribution based on a particular value for one or more input parameters (when using OPTIMIZE FOR ( #variable_name { UNKNOWN | = literal_constant } [ , ...n ] )). Please note that you can still use the UNKNOWN keyword to assume an average distribution for specific parameters while also using specific values for other parameters. For more info, please see the MSDN page for Query Hints.
Parameterized Dynamic SQL (i.e. 'Field = #Param'): This option solves the problem of various combinations of parameters (which you have tried to solve using the Field = #Param OR #Param IS NULL method). And this might be all you need if the data in the ExternalId field is fairly evenly distributed. But if it is very uneven, then you can still fall into the problem of getting a bad cached plan.
Literal (i.e. non-Parameterized) Dynamic SQL (i.e. 'Field = ' + CONVERT(NVARCHAR(50), #Param)): In this method you would concatenate the appropriate parameter values into the Dynamic SQL (after making sure that #ExternalId does not have any single-quotes in it so as to avoid SQL Injection). This will give you a query plan that is tailored to the specific values and can be reused if those values are passed in again (in the exact combination of both input parameters). The main downside here is that if there is a high variability of values passed in for either input parameter, you will generate quite a lot of execution plans, and they do take up memory. But in the case of highly varied data distributions (i.e. one #ExternalId pulls 50 rows while another value pulls 2 million), then this probably the way to go.
Combination of Parameterized and non-Parameterized Dynamic SQL: In the case where an input parameter's values are highly varied but the data distribution in the table is fairly even, you can parameterize this parameter in the Dynamic SQL while concatenating in the input parameter that has a highly varied data distribution. Of course, in this particular situation, we know that Id is very evenly distributed, so if ExternalId is also evenly distributed then you should stick with Parameterized Dynamic SQL (as noted above). This would result in fewer execution plans than going with the fully Literal option.
I have had great success using this technique with stored procedures that get called every second for several hours, and that hit several tables that have well over 10 million rows each. This is after I initially tried using OPTION (RECOMPILE) only to find that it made things worse.
Multiple Stored Procedures: Assuming that you don't ever call this proc with both input parameters being NULL at the same time, you could create three stored procedures for the combinations of: #Id-only, #ExternalId-only, and both #Id and #ExternalId. And it would then be up to the app code to determine which stored procedure to execute. This would seem to be great for the #Id-only proc since the data is evenly distributed. But depending on how evenly or unevenly the values for ExternalId are distributed, the two stored procedures with the #ExternalId input parameter could still run into the problem of getting a bad cached plan.
Notes
When I say "bad cached plan", I mean "bad" for some values. Execution Plans are cached the first time the stored procedure is executed. They are cached until SQL Server restarts, or some executes DBCC FREEPROCCACHE, or if the system is experiencing memory pressure and needs to free up some memory to be used for queries, it can dump plans that haven't been used in a while. But the plan that is cached was intended to be the optimal plan for the parameter values it first ran with. Different values used in subsequent executions might be horribly inefficient with that same plan. So the "bad" refers to a sometimes condition, not an always condition. If the plan is always bad, then it is most likely the query itself is the issue and not the parameter values.
A downside to Dynamic SQL is that it breaks ownership chaining. This means that, typically, direct table permissions need to be granted to the user since the permissions cannot be assumed via owner of the stored procedure. The good news, however, is that you don't need to grant direct table permissions to the User(s) executing the stored proc. You can do the following to maintain proper security when using Dynamic SQL:
I Assume that we are only dealing with a single database.
Create a Certificate in the database
Create a User based on that Certificate
Grant the table permissions to this new Certificate-based User
Use ADD SIGNATURE to sign the stored procedure, which effectively grants the stored procedure -- not the User executing the stored procedure -- the permissions assigned to the new Certificate-based User.