We will go over how to optimize Stored Procedure with making simple changes in the code. Please note there are many more other tips, which we will cover in future articles.
- Include SET NOCOUNT ON statement: With every SELECT and DML statement, the SQL server returns a message that indicates the number of affected rows by that statement. This information is mostly helpful in debugging the code, but it is useless after that. By setting SET NOCOUNT ON, we can disable the feature of returning this extra information. For stored procedures that contain several statements or contain Transact-SQL loops, setting SET NOCOUNT to ON can provide a significant performance boost because network traffic is greatly reduced.
CREATE PROC dbo.ProcName
AS
SET NOCOUNT ON;
--Procedure code here
SELECT column1 FROM dbo.TblTable1
-- Reset SET NOCOUNT to OFF
SET NOCOUNT OFF;
GO
- Use schema name with object name: The object name is qualified if used with schema name. Schema name should be used with the stored procedure name and with all objects referenced inside the stored procedure. This help in directly finding the complied plan instead of searching the objects in other possible schema before finally deciding to use a cached plan, if available. This process of searching and deciding a schema for an object leads to COMPILE lock on stored procedure and decreases the stored procedure’s performance. Therefore, always refer the objects with qualified name in the stored procedure like
SELECT * FROM dbo.MyTable -- Preferred method
-- Instead of
SELECT * FROM MyTable -- Avoid this method
--And finally call the stored procedure with qualified name like:
EXEC dbo.MyProc -- Preferred method
--Instead of
EXEC MyProc -- Avoid this method
- Do not use the prefix “sp_” in the stored procedure name: If a stored procedure name begins with “SP_,” then SQL server first searches in the master database and then in the current session database. Searching in the master database causes extra overhead and even a wrong result if another stored procedure with the same name is found in master database.
- Use IF EXISTS (SELECT 1) instead of (SELECT *): To check the existence of a record in another table, we uses the IF EXISTS clause. The IF EXISTS clause returns True if any value is returned from an internal statement, either a single value “1” or all columns of a record or complete recordset. The output of the internal statement is not used. Hence, to minimize the data for processing and network transferring, we should use “1” in the SELECT clause of an internal statement, as shown below:
IF EXISTS (SELECT 1 FROM sysobjects
WHERE name = 'MyTable' AND type = 'U')
- Use the sp_executesql stored procedure instead of the EXECUTE statement.
The sp_executesql stored procedure supports parameters. So, using the sp_executesql stored procedure instead of the EXECUTE statement improve the re-usability of your code. The execution plan of a dynamic statement can be reused only if each and every character, including case, space, comments and parameter, is same for two statements. For example, if we execute the below batch:
DECLARE @Query VARCHAR(100)
DECLARE @Age INT
SET @Age = 25
SET @Query = 'SELECT * FROM dbo.tblPerson WHERE Age = ' + CONVERT(VARCHAR(3),@Age)
EXEC (@Query)
If we again execute the above batch using different @Age value, then the execution plan for SELECT statement created for @Age =25 would not be reused. However, if we write the above batch as given below,
DECLARE @Query NVARCHAR(100)
SET @Query = N'SELECT * FROM dbo.tblPerson WHERE Age = @Age'
EXECUTE sp_executesql @Query, N'@Age int', @Age = 25
the compiled plan of this SELECT statement will be reused for different value of @Age parameter. The reuse of the existing complied plan will result in improved performance.
- Try to avoid using SQL Server cursors whenever possible: Cursor uses a lot of resources for overhead processing to maintain current record position in a recordset and this decreases the performance. If we need to process records one-by-one in a loop, then we should use the WHILE clause. Wherever possible, we should replace the cursor-based approach with SET-based approach. Because the SQL Server engine is designed and optimized to perform SET-based operation very fast. Again, please note cursor is also a kind of WHILE Loop.
- Keep the Transaction as short as possible: The length of transaction affects blocking and deadlocking. Exclusive lock is not released until the end of transaction. In higher isolation level, the shared locks are also aged with transaction. Therefore, lengthy transaction means locks for longer time and locks for longer time turns into blocking. In some cases, blocking also converts into deadlocks. So, for faster execution and less blocking, the transaction should be kept as short as possible.
- Use TRY-Catch for error handling: Prior to SQL server 2005 version code for error handling, there was a big portion of actual code because an error check statement was written after every t-sql statement. More code always consumes more resources and time. In SQL Server 2005, a new simple way is introduced for the same purpose. The syntax is as follows:
BEGIN TRY
--Your t-sql code goes here
END TRY
BEGIN CATCH
--Your error handling code goes here
END CATCH
Reference: Pinal Dave (http://blog.SQLAuthority.com)
pinaldave
A very useful collection of tips.
Though I would expect a few people to come up with the ‘it depends’ and ‘not always’ arguments, this is certainly a helpful set of tips/best-practices that every TSQL developer should add to his/her check list.
Please, when you post something that you are trying to explain it to the community, provide samples like in your other posts, for me is very abstract sample about Try and Catch
BEGIN TRY
–Your t-sql code goes here (give a example here)
END TRY
BEGIN CATCH
–Your error handling code goes here (give a example here)
END CATCH
Anyway thank you for the tips…
Knowing that it is there to use, you could always take a look in Books Online or search elsewhere for in depth examples. There are lots of examples and trying them out will help you understand how it works more clearly. This set of tips doesnt go in to depth on any of the items as they each could have an article on their own.
If i am using temporary tables, local and global in some of my store procedures, should i use indexes (clustered & non-clustered) on these tables to get maximum performance, specially when i know that these temporary tables will contain lot of rows ???
Hello Aasim,
Creating an index to be used for once would not provide any improvement because processing consumed to create an index itself would overcome the benifit of its uses. We should create an index on any table (permanent or temporary table) if that is usable in more than one statements.
Regards,
Pinal Dave
Hello Aasim,
Like SQL Genius (Pinal) said, if we use temp tables more than once in stored procedure, then definitely it is suggested to create indexes on temporary tables especially when you are dealing with huge amounts of data.
I have seen significant differences in my procedure performance after I created Indexes on huge temp tables.
~ IM.
I would create an index if a temp table contained a lot of rows and was going to be used to join another table.
Hello Pinal,
Sorry, but I disagree with your statement about there is no sense for creating an index on # table if this index will be used just once. Many times in my practice “creation index on the fly” saved tens of minutes, sometimes hours on data processing. It is all about data amount. Sometimes you can’t avoid of using a # table and that table becomes huge in some cases. When we talking about million records temporary table and we have to join this table with another multimillion table we have to create indexes otherwise we can wait forever till procedure is completed.
When we have deal with VLDB, the creation of index(es) on # table on the fly is definitely solution.
BTW, very nice site, I like it, thank you!
Thanks,
IgorA
Aasim,
I would profile the procedure with/without indexes, and then decide what is the actual best practice for your case.
A very good the article.
Hi Pinal,
Nice set of tips, especially the one on execute and sp_executesql.
Thank you
Ramdas
Hello!
Interesting that you wrote this article today. Along with my other responsibilities, I am also part of the DBA team and was working on a code review today and recommended the usage of schema qualifiers (dbo.MyStoredProcedure) for the stored procedures. I had logically thought it through and was going to do a little experiment tomorrow to see the performance difference that qualifers provide. I will run the test tomorrow and update if time permits.
Great compilation, by the way. I agree with Jacob – this should be part of every database developer’s/administrator’s checklist.
Have a Great Day!
Use schema name with object name:
I executed the both queries with schema name and without schema name and checked the execution plan of both the queries.I didn’t find any differrence.
Does anyone have solution how to prove this tip?
whenever we execute any SELECT query first database engine checks in master database. if it’s not there in master database it checks in the current session database depends on schema.
Thanks for some great tips that I am sure to use!
Thanks a lot. Very useful tips
Very Good Tips for Writing Stored Procedure.
It help a lot when you are not familiar in writing SP in sql server.
Regarding using point on
Use IF EXISTS (SELECT 1) instead of (SELECT *):
There is no guarantee SELECT 1 will outperform SELECT *
Also the result is a boolean value and it doesn’t matter how many columns are used inside EXISTS
Regarding using point on
Use IF EXISTS (SELECT 1) instead of (SELECT *):
There is no guarantee SELECT 1 will outperform SELECT *
Also the result is a boolean value and it doesn’t matter how many columns are used inside EXISTS
Well, I would think that in the case of EXISTS the subquery is terminated when first matching row is found and only boolean value is returned. This would seem logical.
But since MSDN doesn’t say anything about this I think the safest way would be to use:
EXISTS (SELECT TOP(1) 1 FROM foo WHERE bar = ..)
This is because if subquery isn’t terminated it would do the matching against all the rows in ‘foo’ and return 0..n rows. This means that there would be 0..n unneccessary matching operations and 0..n * column_count data readings.
With TOP(1) you tell that you are only insterested in the first matching row and no subsequent rows are matched. And because you are returning constant value 1 there will be no unnecessary read operation to the table.
Okay. I went ahead and tested this. It seems that there’s no diffence between any of these:
SELECT 1 FROM MyTable WHERE EXISTS (SELECT * FROM MyTable)
SELECT 1 FROM MyTable WHERE EXISTS (SELECT 1 FROM MyTable)
SELECT 1 FROM MyTable WHERE EXISTS (SELECT TOP(1) 1 FROM MyTable)
I’ve heard from others to use EXISTS (SELECT *) because it allows SQL Server to select the best index. Also, the exists clause causes it to select only one row
@rudesyle
INDEX usage would not be based on the *, but on the WHERE clause. Think about it, EXISTS causes a lookup which we are hoping to be an INDEX scan of sorts. The match is based on the WHERE clause where the correlation is defined.
@Madhivann
Technically, SELECT 1 is faster: http://www.sqlskills.com/BLOGS/CONOR/2008/02/default.aspx?page=2
Brad Schulz has a nice write-up here: http://bradsruminations.blogspot.com/2009/09/age-old-select-vs-select-1-debate.html
Personally, i use * because it states explicitly “i don’t want the results”. Anything else might give the developer pause.
Brian,
From link1
However, at runtime the two forms of the query will be identical and will have identical runtimes.
So SELECT 1 is not faster
Aslo from link2
Sure, it will take a couple of extra femtoseconds to compile (compared to the boring SELECT 1),
See the definition of femtoseconds
It is actually very negligible in real time
http://en.wikipedia.org/wiki/Femtosecond
@Madhivanan
Yes, but the expansion itself takes time! :)
When Brad said femtoseconds, he was being facetious.
The idea here is, it does take longer, just not much. As is a very, very, very, very, very, very, tiny bit longer.
Pinal, this is great stuff!
Guys – regarding the “select 1″ versus “select *”, I feel you are missing something here.
I have seen notable peformance improvements by using SELECT 1 instead of SELECT *. Looking at the Execution Plan to address to performance, I could see that SELECT * was having to bring back all fields using the clustered index. When SELECT 1 was used instead, a covering index based on the WHERE clause was used by the engine and performance was notably better. As in a query taking 4 secs now takes 0.15 secs.
Also, from a developers point of view, SELECT 1 is preferred because it is symantically stating that the fields are not important to the query.
Thanks Pinal . It’s a great tips.
These tips are very useful an SQL Developer!!!
Thanks Pinal
Beginner like me it’s a great tips.
As Madhivanan points out, there is no benefit in the ‘select 1′ syntax over ‘select *’ if you’re using ‘if exists’ at the same time.
There is no data processed from the query inside the ‘exists’ clause and so it makes no difference what you ‘select’. Books Online’s examples for the ‘exists’ keyword uses the ‘select *’ syntax.
A much more important point to make is not to perform a count and compare it to zero (a lot of people seem to do this) – so:
if (select count(*) from …) > 0
is especially bad, and should be replaced with
if exists (select * from …)
instead.
Great Article
Tips will helpful so much for beginners like me
Thank You
This is great. Thank you all for great participation.
I am really expecting more experts to come and share their suggestions.
Nice set of tips.
A couple of things that every developer should realize is that before directly jumping to tune your stored procedures, make sure you have checked your table size, schema, index information etc etc. Most of the times, the ’cause’ of slow performing queries is bad design.
Check the Tuning advisor http://msdn.microsoft.com/en-us/library/ms166575.aspx
Thanks Pinal,
lovely tips… are they only or there exists any more tips?
Thanks,
Nitin Sharma
Best stored procedures optimization tip => do NOT use them!
Do you have any valid reasons?
Hi,
On the part where you’ve suggested not to use the ‘SP_’ prefix. Wouldn’t that be a problem only if you are creating stored procedures using the dbo schema.
Please elaborate the issue.
Regards.
Hello Hamza,
A stored procedure with prefix “sp_” whether in dbo schema or user defined schema, whether fully qualified name or non-qualified name, always first checked in master database. And if your stored procedure is in another database then an extra search would be an overhead every time you call that stored procedure.
Regards,
Pinal Dave
I have seen in one of the blogs to use EXISTS like
IF EXISTS(Select null from table)
Will it optimize the perfomance better than
IF EXISTS(Select 1 from table)
?
@Divya
It makes no difference what is put there.
Brad Schulz has an interest article on it: http://bradsruminations.blogspot.com/2009/09/age-old-select-vs-select-1-debate.html
Even 1/0 is allowed! Obviously, it is not evaluated.
Technically, however, * does get expanded, adding some minuscule amount of time: http://www.sqlskills.com/BLOGS/CONOR/2008/02/default.aspx?page=2
So, anything other than * takes the same amount of time. * takes an iota longer. Personally, i use *, to show that i do not care what the results are.
Hello Divya,
I not think so because there is no significant difference in transferring of 1 byte and a null value.
Other than that there is no difference between these two queries.
Regards,
Pinal Dave
“I not think so because there is no significant difference in transferring of 1 byte and a null value.”
While that is true in this exact case I like to be pedantic about this and elaborate this a bit and probably confuse everybody up :)
There is no concept NULL value if you think about C code or even the CPU. Pointers in C can have NULL values but that just means that the pointer is pointing to memory in the address 0×00000000 (in 32-bit machine). The actual pointer is still taking sizeof(VOID*) amount of memory even when it points to NULL.
Now if you think about functions in C or any other language they always reserve space in the function stack for the return value. You can say, again in C, that you don’t care about the return value and declare the function to return “void” but still it takes 4 bytes of memory in 32-bit machine for return value.
And actually, of you think about the CPU, there is 32 bit register reserved exactly for this.
And now considering that it makes no difference to return one byte or four bytes since there is space for four bytes anyway. And in fact, many times (all the times?) when you deal with C data types CHAR (1 byte) or SHORT (2 bytes) you end up taking 4 bytes because of the padding to keep memory aligned.
Uh! I almost felt like going back in time some ten years when I was writing kernel drivers for Windows :)
Thank you Marko for providing the details about memory allocation of NULL value.
Regards,
Pinal Dave
Good stuff! Would love a follow up on table/scalar functions performance.
Very good tips, useful for sql developers.
@Brian,
Nice blog posts
But none of them proved that SELECT 1 will outperform SELECT *. They only guess it
@Madhivanan
The Conner article does explain about the extra action being done. Whether this is noticeable or not is another question. But it is an extra action over a non-* query.
Thanks for another great post! You continue to provide great posts to the SQL-community.
Sir, This is very useful tips for my site. But also have one problem.
I am searching for a stored procedure which will eliminate all the STOP words like “in”, “the” in my query and accordingly search the result.
Is it correct :-
//This is my stored procedure
CREATE PROCEDURE sp_GetInventory
@location varchar(50) AS
select column1, column2 from table1
where column1 like ‘%SearchString%’ or column2 like ‘%SearchString%’
EXECUTE sp_GetInventory ‘SearchString’
Dear pinal,
very useful tips for Optimization for stored procedures.
Yes it is really good performance not using SP_ProcName.
We are using instead as dbo.USP_ProcName means UserStoredProcedure
[...] 21, 2010 by pinaldave Few days ago I wrote article about SQL SERVER – Stored Procedure Optimization Tips – Best Practices. I received lots of comments on particular blog article. In fact, almost all the comments are very [...]
Hello Pinal Sir,
These tips are very useful for me…..
Thanks….
It is very helpful article, but I have one comment about the point
Do not use the prefix “sp_” in the stored procedure name: If a stored procedure name begins with “SP_,” then SQL server first searches in the master database and then in the current session database. Searching in the master database causes extra overhead and even a wrong result if another stored procedure with the same name is found in master database.
I created two stored procedures with the same name in “Master” and “Another new DataBase”, and I executed it from the new one.
The result returned from the new one.
This mean that, it didn’t execute the one in the Master, although there’s a SP in the Mater with the same name.
Can you please elaborate this.
This is a killer post since optimizing database code or SQL statements is a killer job.
However the hints provided here are very useful. Simple optimization hints, that anyone can use, and more advanced but still easy to understand.
About the SELECT 1 versus the SELECT * i think that the first should be preferred over the last.
A few years ago i came across a few optimization tips for Oracle (my previous professional background) and this tip was already mentioned. But later i read that Oracle internally optimizes EXIST (SELECT * FROM …). Perhaps the same approach is used inside SQL Server and that’s why the difference isn’t noticed.
The reason stated for using SELECT ‘ANY_CONSTANT’ over SELECT * is that * would read every column, so it would be more efficient to return a constant. The gains would be obtained in the reduced reading of data.
Regards.
Great article!
Use schema name with object name:
I executed the both queries with schema name and without schema name and checked the execution plan of both the queries.I didn’t find any differrence.
Does anyone have solution how to prove this tip?
Hello Swati,
The difference will be considerable when the queries involves too many tables,views and processes large amount of data.
Regards
Sheju
Pinal,
If we execute the Stored procedure starting with “sp_”
by this way
Exec DBname.dbo.SPname
SQL engine directly go on specified database instead of master DB to search that sp.
Is it right? Let me know your comments.
Thanks
Darshan Shah
Yes. That is correct
i have confused about store procedure becuase query is good to procedure plz expain full how to store procedure and what is use of bussiness inudstires
Hi Pinal,
Could you please tell some what in detail about performance tuning, may be with an example like – If a query takes more time what are all the causes for that or if a stored procedure takes more time what are all causes for that so that many DBA’s as like me who are all in intermediate stage would gain a lot . Thanks!
good afternoon all the query is used to table but what is used of trigges and stored procedure because query is profitable in table but what is used of procedure in table
i dont know what is used of procedure,triggers
plz define with example
what is used of table and database
thankyou
Pinal:
How would one discover / prove via a trace “Do not use the prefix “sp_” in the stored procedure name….first searches in the master database and then in the current session database”
awsome article sir
Truly amazing article…..Really thankful to you Mr.Pinal..
Hi Pinal and all the readers
Nice article..
Btw one more tips of using DDL and DML query..
Always use the DDL queries like create table or drop table first and then use DML query like Select, Update or Delete
As DDL queries always need a recompilation of procedures in order to make the changes in our DML Queries
Nice Artical.
Thanks a lot. Very nice explanation
gr8 article ,,thx Pinal
hi all,
regd. sql sp, i face the prob. regd. passing date value…
it gives error ‘Invalid syntax at date-part..’
here i give u the code 4 sp …
CREATE Procedure BimstInsert
(@Date Datetime,@Pc Numeric(6,0),@Ic Numeric(6,0),@Qt Numeric(6,0))
As
Begin
declare @ra Numeric(6,2)
Declare @ch Numeric(6,0)
Select @ra=I.Rate from ItemMst As I
Where @Ic=I.Code
Select @ch=IsNull(Max(B.ChNo),0)+1 from BiMst As B
Insert into BiMst Values
(@ch,@Date,@Pc,@Ic,@Qt,@ra,(@Qt*@ra))
End
———————————————————–
exec BimstInsert (’10/jan/2010′,1,1,10)
i also tried for diff. date style…
pls. help me
thanks in advance…
bye…
You need to use unambiguous format like YYYYMMDD. Refer this post for more informations
http://beyondrelational.com/blogs/madhivanan/archive/2010/06/03/understanding-datetime-column-part-ii.aspx
where are the values which you passing in
Insert into BiMst Values
(@ch,@Date,@Pc,@Ic,@Qt,@ra,(@Qt*@ra))
the value must me in datetype format which you will be passing in @date
Hi sir,
I am fresher and i am working in welcomenetwork company
i have string like ’0012340056789′
but i want only the string like ’12340056789′
that is starting 0 should be removed so how can i
do in sql server function
Reply
Thanks & Regards,
Dipak B. Kansara
select cast(col as bigint) from your_table
Some of my most impressive performance improvements have come from replacing cursor-based code with carefully constructed set-based processing. That tip alone can pay the bills…
Is it better to have multiple small stored procedure or one big stored procedure (Combining multiple sp into one and having some conditional logic in it to choose which sql should be used) ?
I love to have multiple stored procedure specific to the user request in place of having one which can serve all kinds of request but i need some better reasons for it.
Thanks for the all your help over the years…
I think it is better to have seperate procedures so that it is easy to maintain. If the result set contains different number of columns, it is not possible to design a report based on it
Solution for optimizing SQL stored Procedures are WITH (ROWLOCK) for insert, update and select, and if you dont do any calculation on your syntax you can use also WITH (NOLOCK).
Nice site..
Good Site