August 29, 2024 at 8:52 am
Already done that, scroll up a little bit.
August 29, 2024 at 8:54 am
I have already done that, scroll up a few posts.
EDIT: Sorry, duplicate post.
August 29, 2024 at 9:55 am
if it is nvarchar it should be WHERE param=N'p1' instead of WHERE param='p1'
August 29, 2024 at 10:33 am
Yes, I was obviously lazy typing it here, sorry, it looks like the way you wrote it.
August 29, 2024 at 10:42 am
This was removed by the editor as SPAM
August 29, 2024 at 11:09 am
Already done that, scroll up a little bit.
apologies - missed that reply.
this is around the issue I thought - and not much you can do about it other than remove the "key lookup" you have as this will always make it slower and have more IO.
so your Object3 at the moment requires a index seek + keylookup to get all required data - depending on your table structure and how it is used elsewhere you may consider changing the clustered index to have your Column5 as the first column on the index. investigate very well if this would be a possibility as it may slow down other queries as well as inserts/deletes.
if changing clustered index not feasible, then consider changing the current index being used (should have column5 and column6 on it already (column6 likely clustered key column)) and add as include Column 2, 4 and 7) - pretty much ensure you have a index that contain the columns referenced on the Missing indexes list. so either a new index or change an existing one (normally better to change)
Reason for these type of queries to go slow when there is a "OR" is that the only way to satisfy the query is to retrieve significant amounts of data from the tables involved, and only after this a "filter" is can be applied (on this case the filter is the offset/fetch x rows only).
and when only 1 value is specified (e.g. no OR) then it can filter at source and it only retrieves the required data from underlying tables.
Viewing 6 posts - 16 through 20 (of 20 total)
You must be logged in to reply to this topic. Login to reply