<a href="http://g.adspeed.net/ad.php?do=clk&zid=15220&wd=468&ht=60&pair=as" target="_blank"><img style="border:0px;" src="http://g.adspeed.net/ad.php?do=img&zid=15220&wd=468&ht=60&pair=as" alt="i" width="468" height="60"/></a>
Log in
::
Register
::
Not logged in
Home
Tags
Articles
Editorials
Stairways
Forums
Scripts
Videos
Blogs
QotD
Books
Ask SSC
SQL Jobs
Training
Authors
About us
Contact us
Newsletters
Write for us
<a href="http://g.adspeed.net/ad.php?do=clk&zid=15491&wd=120&ht=300&pair=as" target="_top"><img style="border:0px;" src="http://g.adspeed.net/ad.php?do=img&zid=15491&wd=120&ht=300&pair=as" alt="i" width="120" height="300"/></a>
Recent Posts
Recent Posts
Popular Topics
Popular Topics
Home
Search
Members
Calendar
Who's On
Home
»
SQL Server 7,2000
»
Performance Tuning
»
Temporary variables in SQL
Temporary variables in SQL
Rate Topic
Display Mode
Topic Options
Author
Message
tharucse
tharucse
Posted Tuesday, January 11, 2011 1:48 AM
Grasshopper
Group: General Forum Members
Last Login: 2 days ago @ 10:25 PM
Points: 13,
Visits: 157
I found that some people are using temporary variables with stored procedures just to increase the performance of the query.No particular need for temp variables there.It's like this.If we want to insert some values in a table then
Create PROCEDURE MyStoredProcedure
(
@param1 INT OUTPUT,
@param2 varchar(40)
)
As
DECLARE @temp1 INT
SET @temp1=@param1
DECLARE @temp2 varchar(40)
SET @temp2 =@param2
Insert into Table_1(Field1,Field2)values(@temp1,@param2)
I just could not imagine how this will improve the performance.For me it seems in the other way.Can anyone please help me to understand this?
Thanks.
Post #1045736
GilaMonster
GilaMonster
Posted Tuesday, January 11, 2011 2:56 AM
SSC-Dedicated
Group: General Forum Members
Last Login: Today @ 4:08 PM
Points: 38,099,
Visits: 30,392
It's used when you run into problems with parameter sniffing.
http://sqlinthewild.co.za/index.php/2007/11/27/parameter-sniffing/
Gail Shaw
Microsoft Certified Master: SQL Server 2008, MVP
SQL In The Wild
: Discussions on DB performance with occasional diversions into recoverability
We walk in the dark places no others will enter
We stand on the bridge and no one may pass
Post #1045757
tharucse
tharucse
Posted Tuesday, January 11, 2011 3:55 AM
Grasshopper
Group: General Forum Members
Last Login: 2 days ago @ 10:25 PM
Points: 13,
Visits: 157
Thanks Gail.I'll go through it and get back to you if I have any issues.Again Thanks a lot..
Post #1045775
tharucse
tharucse
Posted Tuesday, January 11, 2011 8:54 PM
Grasshopper
Group: General Forum Members
Last Login: 2 days ago @ 10:25 PM
Points: 13,
Visits: 157
In search queries when data distribution is skewed parameter sniffing can be a problem and local variables can be used to solve it.But I really don't understand how this comes into play when we do inserts.
Post #1046241
GilaMonster
GilaMonster
Posted Tuesday, January 11, 2011 10:41 PM
SSC-Dedicated
Group: General Forum Members
Last Login: Today @ 4:08 PM
Points: 38,099,
Visits: 30,392
It doesn't. No use or benefit whatsoever.
Gail Shaw
Microsoft Certified Master: SQL Server 2008, MVP
SQL In The Wild
: Discussions on DB performance with occasional diversions into recoverability
We walk in the dark places no others will enter
We stand on the bridge and no one may pass
Post #1046259
tharucse
tharucse
Posted Wednesday, January 12, 2011 4:35 AM
Grasshopper
Group: General Forum Members
Last Login: 2 days ago @ 10:25 PM
Points: 13,
Visits: 157
Thanks Gail.I just asked one person who has this practice of using temporary variables.They say that they keep it as a standard way to write sql procedures even there is no use in insert queries Because can not expect all the developers to think in an intelligent way before write queries when it comes to a particular query that may have performance issue because of parameter sniffing.
Post #1046386
GilaMonster
GilaMonster
Posted Wednesday, January 12, 2011 5:10 AM
SSC-Dedicated
Group: General Forum Members
Last Login: Today @ 4:08 PM
Points: 38,099,
Visits: 30,392
tharucse (1/12/2011)
Thanks Gail.I just asked one person who has this practice of using temporary variables.They say that they keep it as a standard way to write sql procedures even there is no use in insert queries Because can not expect all the developers to think in an intelligent way before write queries when it comes to a particular query that may have performance issue because of parameter sniffing.
That's a bad practice. The use of variables for parameter sniffing problems is a specific solution to a specific problem. By using variables everywhere you'll be hindering the optimiser and generally preventing it from finding good execution plans.
Use variables for the parameters only when there really is a parameter sniffing problem and investigation has shown that it is an appropriate solution (rather than rewriting the query or specific query hints). It should not be a standard development practice
http://sqlinthewild.co.za/index.php/2008/02/25/parameter-sniffing-pt-2/
Gail Shaw
Microsoft Certified Master: SQL Server 2008, MVP
SQL In The Wild
: Discussions on DB performance with occasional diversions into recoverability
We walk in the dark places no others will enter
We stand on the bridge and no one may pass
Post #1046403
Jeff Moden
Jeff Moden
Posted Wednesday, January 12, 2011 7:16 AM
SSC-Dedicated
Group: General Forum Members
Last Login: Today @ 7:18 AM
Points: 33,112,
Visits: 27,038
Also, table variables don't necessarily make things any faster than a Temp Table. They both start out in memory... they both write to disk (TempDB) when they get bigger than memory wants to hold.
Table Variables also make it (IMHO) more difficult to troubleshoot a problem in the code because they don't persist after the run is complete in SSMS. That means you have to run the code from the beginning every time or write some code to do some skips. You don't need to do that with Temp Tables because they persist during the session..
--Jeff Moden
"
RBAR
is pronounced "ree-bar" and is a "Modenism" for "
R
ow-
B
y-
A
gonizing-
R
ow".
First step towards the paradigm shift of writing Set Based code:
Stop thinking about what you want to do to a row... think, instead, of what you want to do to a column."
For better, quicker answers on T-SQL questions, click on the following...
http://www.sqlservercentral.com/articles/Best+Practices/61537/
For better answers on performance questions, click on the following...
http://www.sqlservercentral.com/articles/SQLServerCentral/66909/
Post #1046468
« Prev Topic
|
Next Topic »
Permissions
You
cannot
post new topics.
You
cannot
post topic replies.
You
cannot
post new polls.
You
cannot
post replies to polls.
You
cannot
edit your own topics.
You
cannot
delete your own topics.
You
cannot
edit other topics.
You
cannot
delete other topics.
You
cannot
edit your own posts.
You
cannot
edit other posts.
You
cannot
delete your own posts.
You
cannot
delete other posts.
You
cannot
post events.
You
cannot
edit your own events.
You
cannot
edit other events.
You
cannot
delete your own events.
You
cannot
delete other events.
You
cannot
send private messages.
You
cannot
send emails.
You
may
read topics.
You
cannot
rate topics.
You
cannot
vote within polls.
You
cannot
upload attachments.
You
may
download attachments.
You
cannot
post HTML code.
You
cannot
edit HTML code.
You
cannot
post IFCode.
You
cannot
post JavaScript.
You
cannot
post EmotIcons.
You
cannot
post or upload images.
Copyright © 2002-2013 Simple Talk Publishing. All Rights Reserved.
Privacy Policy.
Terms of Use.
Report Abuse.
