Yes, I was obviously lazy typing it here, sorry, it looks like the way you wrote it.

I have already done that, scroll up a few posts.

EDIT: Sorry, duplicate post.

Already done that, scroll up a little bit.

They are all NVARCHAR's so that shouldn't be the problem.

Might have discovered a piece of the puzzle..

When problematic query looks like this.. WHERE param=@p1 it might run fine if I add a relevant index in SSMS, but if I...

There's no way for me to override the NHibernate stuff in the solution I'm working in. It's way too complex and even if I manage to do it, people will...

No I can't use UNION since this is NHibernate generated.. I really prefer good old hand-coded SQL though.. 🙂

I made a simpler query than the actual one but the problem...

I can't share the executionplans (without massive censoring) since it belongs to the place I work sadly.

It would be quite easy try running the query 3 times but since this...

The query is slow (when using all three conditions) no matter what I use, SSMS or app.

The problematic (readonly) query only returns one row with the parameters used when captured with Extended Events so I don't think it's related to huge amounts of data(?) I'm trying...

• This reply was modified 3 months, 2 weeks ago by  oRBIT.

Issue solved, Querystore - storage was too low, we increased the storage and things turned back to normal as far as I can tell.

I attach a screenshot from Querystore, "overall resource consumption" in gridformat. Around the 5:th of may, we upgraded to enterprise version but querystore started to behave odd, as you can...

Most likely scenario is probably a script with lots of INSERTs.

Probably the most annoying thing on internet today, those annoying cookie-dialogs.

Yes, but what about fragmentation? Should I bother? FillFactor? It's easier with just one index-column, not multiple (in my head anyway... :))