﻿<?xml version='1.0' encoding='UTF-8'?><rss version="2.0" xmlns:dc="http://purl.org/dc/elements/1.1/"><channel><title>SQLServerCentral / SQL Server 7,2000 / Performance Tuning  / Stored procedure slower then query / Latest Posts</title><generator>InstantForum.NET v2.9.0</generator><description>SQLServerCentral</description><link>http://www.sqlservercentral.com/Forums/</link><webMaster>notifications@sqlservercentral.com</webMaster><lastBuildDate>Fri, 24 May 2013 20:53:25 GMT</lastBuildDate><ttl>20</ttl><item><title>RE: Stored procedure slower then query</title><link>http://www.sqlservercentral.com/Forums/Topic402194-65-1.aspx</link><description>Try also leaving the parameters and marking the proc for recompile every time it runs. (CREATE PROCEDURE ... WITH RECOMPILE)Using variables, the optimiser can not make any conclusions about the number of rows that will be affected by any query. I believe it will make a guess at about 1/3 of the table. Hence, you're unlikely to get very good performance but you are guarenteed to never get very bad performance. Essentially, you'll get average performanceUsing recompile, you'll get the best possible plan for each run of the procedure at a cost of a slight CPU overhead for the compile.Give it a try and see what's best for you.I will recommend that you don't switch parameters for variables unless you know you are having this kind of problem with a particular proc. It's called parameter sniffing and, in general, it's a good thing.</description><pubDate>Wed, 26 Sep 2007 09:55:06 GMT</pubDate><dc:creator>GilaMonster</dc:creator></item><item><title>RE: Stored procedure slower then query</title><link>http://www.sqlservercentral.com/Forums/Topic402194-65-1.aspx</link><description>THANK YOU!!!!!! I have been fighting with this stored procedure for about 3 days now.  I was sure this was going to kill the last bit of motivation I still had left to optimize this beast.&lt;/P&gt;&lt;P&gt;I had 4 parameters going in to the Stored procedure.  In the query I had declared and set them at the top so I could easy copy/paste when I finished.&lt;/P&gt;&lt;P&gt;I prefixed all the variables coming in to the stored procedure with an o declared the variables in the stored procedure and set them equal to the o prefixed variables and the stored procedure ran as expected.&lt;/P&gt;&lt;P&gt;again THANK YOU. I'll have to try to remember this in case I ever run into it again.  For now I'm off to fix the o variables to make sense.&lt;/P&gt;&lt;P&gt;[quote][b]Lynn Pettis (9/24/2007)[/b][hr]Without seeing the code for the stored procedure, it is a guess.  It could be parameter sniffing at work.  Are you using the variables declared in the header of the sproc in the query?  If so, declare local variables inside the procedure, set those variables to the values you are sending in, and use the local variables in your query.&lt;/P&gt;&lt;P&gt;:cool:[/quote]</description><pubDate>Mon, 24 Sep 2007 13:05:12 GMT</pubDate><dc:creator>Kevin Brown-242904</dc:creator></item><item><title>RE: Stored procedure slower then query</title><link>http://www.sqlservercentral.com/Forums/Topic402194-65-1.aspx</link><description>Without seeing the code for the stored procedure, it is a guess.  It could be parameter sniffing at work.  Are you using the variables declared in the header of the sproc in the query?  If so, declare local variables inside the procedure, set those variables to the values you are sending in, and use the local variables in your query.&lt;/P&gt;&lt;P&gt;:cool:</description><pubDate>Mon, 24 Sep 2007 12:37:17 GMT</pubDate><dc:creator>Lynn Pettis</dc:creator></item><item><title>Stored procedure slower then query</title><link>http://www.sqlservercentral.com/Forums/Topic402194-65-1.aspx</link><description>This is an odd one I just ran into today.  I rebuilt an older query that aggregated together a bunch of information.  The query had slowed down to the point that it was regularly timing out.  &lt;/P&gt;&lt;P&gt;The primary table that is being accessed is about 80k records so it's not a huge data set.  &lt;/P&gt;&lt;P&gt;To optimize the query I removed a table variable that worked similar to this (with more column)&lt;/P&gt;&lt;P&gt;select Type, OrigionalLogID, (select top 1 b.field from table b where b.type=a.type and b.OrigionalLogID=a.OrigionalLogID and TranType in ('these', 'change') order by b.field desc), .... into @table from table a where .... order by OrigionalLogID&lt;/P&gt;&lt;P&gt;I built a view that used min/max(case ...) to build the same data.  Doing that dropped a considerable amount of time off of the execution time of the query and simplified things considerably.&lt;/P&gt;&lt;P&gt;I then rebuilt fields that were selected as (select) as fieldname into count(case ...) statements to speed things even further.  I managed to drop the query that ran for 60 seconds for a month of data to run in about 2 seconds for a month, and about 7 seconds for a full history.&lt;/P&gt;&lt;P&gt;I then took the query I had built and copied it into a stored procedure created the procedure and executed with the same parameters I was using for test and the stored procedure takes over 2 min to execute (it generates the exact same execution plan)&lt;/P&gt;&lt;P&gt;Does anyone have any idea what could be breaking or how I could fix it?&lt;/P&gt;&lt;P&gt;thanks,&lt;/P&gt;&lt;P&gt;  Kevin</description><pubDate>Mon, 24 Sep 2007 12:25:33 GMT</pubDate><dc:creator>Kevin Brown-242904</dc:creator></item></channel></rss>