Why is this Sproc Scanning Table [closed] - sql

Question

Closed. This question does not meet Stack Overflow guidelines. It is not currently accepting answers.
This question does not appear to be about programming within the scope defined in the help center.
Closed 9 years ago.
Improve this question
This system was built years ago in SQL7 and currently runs in SQL2k5
We have a table tProducts with a proudctid Guid as the PK/Clustered Index. I realize for optimum performance we should modify the table but that's not a possibility at this point. I'm joining it to the tProductSpecial table which also has a PK/Clustered Index of productid, which is also the FK in this relationship. We have about 50k records in the tProducts table and about 35k records in the tProductSpecial table (some products have special information and some do not). There is one more piece. I am using a Temporary table in the sproc to grab the logged in users security roles and loading them, this also joins to the tProducts table, roleid is non-clustered index in tProducts. I've included some of the WHERE conditions that access these table.
SELECT *
FROM tProducts
JOIN tProductSpecial ON tProducts.productid=tProductSpecial.productid
JOIN #tRoles ON tProducts.roleid=#tRoles.roleid
WHERE
(tProducts.productSKU = #sku AND tProducts.productStatus=1) --DIRECT MATCH
OR
( -- KEYWORD SEARCH
CONTAINS(tProducts.*,'FORMSOF(INFLECTIONAL,''' + #lookuptext + ''')')
AND
(
#productStatus IS NULL
OR
(
#productStatus IS NOT NULL
AND
tProducts.productStatus = #productStatus
)
)
AND
( --- item on sale
#bOnSale IS NULL
OR #bOnSale=0
OR
(
#bOnSale = 1
AND tProducts.productOnSale=1
)
)
AND
( -- from price
#from=0
OR #from IS NULL
OR
(
#from<>0
AND
tProducts.customerCost>=#from
)
)
AND
( --to price
#to=0
OR #to IS NULL
OR
(
#to<>0
AND
tProducts.customerCost<=#from
)
)
AND
( --how old is product
#age IS NULL
OR #age = 0
OR
(
#age IS NOT NULL
AND #age > 0
AND DATEDIFF(day,tProducts.productCreated,GETDATE())
<=CONVERT(varchar(10),#age)
)
)
ORDER BY tProducts.productSKU

Answer 1

The problem is probably due to parameter sniffing - you're using the same plan over and over again even if the parameters are different and only sometimes a scan would be the best approach. In SQL Server 2008, you could simply add OPTION (RECOMPILE) or OPTIMIZE FOR UNKNOWN, but in SQL Server 2005, try altering the stored procedure and adding the WITH RECOMPILE option. This will force SQL Server to consider a new plan every time, based on the incoming parameters.
Another option would be to build up the query dynamically based on whether #bOnSale, #from etc. are populated. In 2005 this will lead to plan cache bloat but you may be better off overall. This could completely avoid the Full-Text access, for example, when #sku is populated. Again, in SQL Server 2008 this is better, as you can stave off some of the plan cache bloat by using Optimize for ad hoc workloads.

Answer 2

A stored procedure of long standing can suddenly develop a case of the poor plan for all sorts of reasons. Just off the top of my head here are a few that stand out:
Index Changes
Dropping/Modifying indices on tables can cause queries that have had a perfectly fine execution plan for years to go south. Solution: don't do that. If you are going to do that, examine the dependencies on that table and make sure that everything is still getting a good execution plan.
Table Statistics
Index statistics can get fouled up for a number of reasons. For instance, large bulk loads of data into table(s) referenced by the stored procedure can bollux up index statistics on that table and thus mislead the query optimizer into constructing a poor execution plan. Solutions include 1 or more of the following:
update statistics on the table(s) involved
run DBCC FREEPROCCACHE to flush the stored procedure cache.
Execute sp_recompile on the offending stored procedure.
Direct References To Stored Procedure Parameters
Stored procedures whose queries directly use the parameters passed into the stored procedure get an execution plan based on the value of the parameters on the stored procedures first execution, when the plan is created and cached. If those parameter values are a little outré, the cached execution plan may perform well for the oddball cause but extremely poorly for the general case. The short-term Solution is torun sp_recompile or modify the stored procedure so that has the with recompile option (Note however, that this has a significant performance impact since the stored procedure gets recompiled for every execution. That means that compile locks are taken during the compilation process and that can (and does) cause blocking.
The correct fix for this problem is to declare a local variable within the stored procedure and set it to the value of the parameter. That turns the parameter value to an expression and breaks the plan's dependency on the parameter value. Floored me the first time I got hit with this problem.
Good luck!