Based on the number of connection requests I received today and yesterday, I assume people are talking during the PASS Summit.
I can only say thank you; the stories are grossly overestimated in my favour.
I've decided to highlight blog posts that have helped me out when they help me out.
Rather than just read, action, then forget.
So thank you @Kendra_Little for your post on "NO_PLAN and NO_INDEX: Breaking a Forced Query Store Plan"
littlekendra.com/2016/03/25/no_…#SQLServer
@SOZDBA If I've read through this correctly, @PaulRandal bogged this back in 2010 and this comment in 2019 could indicate it may still not be fixed:
#comment-1169121" target="_blank" rel="nofollow noopener">sqlskills.com/blogs/paul/mis…
#SQLServer challenge for anyone who likes figuring things out.
I've created the index it asked me to.
Run the query again, and it suggests the same index
**even though it uses it**
I can replicate but I can't figure out why.
Anyone want to try to replicate it? 😇😈
Final trick, and thanks to those that responded, I now know more than before.
I can only replicate this with these conditions:
1. FULL optimization
2. Range comparison on 1 of the columns,
3. Partitioned table (Yes, I was sneaky and didn't mention this)
Not sure if this is a hint, but the issue is only present when the query goes through Full Optimization.
When it's Trivial Optimization, no missing index shows, and the query uses the index fine.
That's why I had to add
AND (SELECT 1) = (SELECT 1);
to the WHERE clause
@feaselkl@sqL_handLe Interesting, the range could be something to do with it.
Changing the range to an equality does change the order.
When that index replaces the order one, no missing index recommendation shows
(must read that link fully to try and figure out why)