I have a T-SQL stored procedure with the signature
CREATE PROCEDURE MyProc
@recordCount INT OUTPUT
@param1 INT
...
When executed directly i
In short - I fixed my issue by forcing SQL Server to use the most appropriate index to limit lob logical reads when it couldn't figure it out on its own.
In long -
I just ran into this issue and resolved it in a different way after trying all of the other suggested answers. In SSMS the query was running in ~3s, but was timing out when called from a .Net MVC web application.
Statistics IO output in SSMS was telling me that there were over 195,500,000 lob logical reads on one table (20M-row table with a clustered columnstore index and also has row indexes, but has no "LOB" columns). I noticed from the execution plan that a bulk of the load (76%) was coming from an index seek on one of the row indices. I used the following:
from [table] with (index([clustered columnstore index name]))
in my query to force the usage of the clustered columnstore index and my query was reduced to <1s and the lob logical reads dropped to <6k from >195M, and when calling the SP from the web app now, it is round-tripping in 1.3s.
I tried option recompile, set arithabort on, parameter sniffing, and in the end SQL Server just couldn't figure out which index to use. This is an edge case too btw, and the only time I have had to force an index in this database.