Comments on: Covering, schmuvvering – when a covering index is actually rubbish

By: Rob Farley

Rob Farley — Mon, 14 Dec 2015 01:33:46 +0000

The NC index is designed to be weak - that's why I had to use a hint to get it to be used in the first case. But the point about having an ineffective index holds. People frequently kill the impact of a composite index by using an inequality, or apply a function so the index key can't be used at all - and if there's a leading key which can be used, an Index Seek which produces a small number of rows is seen. It looks good, but isn't. But the impact of this can be seen using trace flag 9130, or now with later service packs on 2012. http://sqlblog.com/blogs/rob_farley/archive/2015/12/12/a-new-superpower-for-sql-query-tuners-number-of-rows-read.aspx

By: Greg Low

Greg Low — Mon, 14 Dec 2015 01:25:18 +0000

That NC index is a pretty weak index though. The index itself (on DaysToManufacture) isn’t selective in the first place, regardless of whether or not the included columns make it cover the query.
I suppose the main issue is how well the QO discerns what’s going on.

By: Rob Farley

Rob Farley — Wed, 03 Oct 2012 16:59:56 +0000

Can you send me an email with the execution plan in it? I’m sure there must be something else going on, as I see little reason in what you’ve written for it to scan rather than seek. You can reach me at hotmail.com, as rob_farley.

By: Rajesh

Rajesh — Wed, 03 Oct 2012 15:32:16 +0000

Hi Rob,
I have a table, having non cluster index say(id,date), but when I am running a query
select id,date from table where id = 1 and date = ‘2010-09-09’
its always performing index scan, while returning only one row..
so why this is happening, when my index is selective only one row itis returning, then why scan also it involvs 98 logical redas..
also this index is not unique, both id and date have duplicate values, but this combination of date and id has only single row.

By: Rob Farley

Rob Farley — Thu, 07 Jul 2011 15:14:12 +0000

Hi Phil,
There are plenty of situations where people try to force indexes to be used because they want a Seek that returns a single row, because they assume that it’s an ideal operation. That’s what I’m trying to challenge.
Rob

By: Phil

Phil — Thu, 07 Jul 2011 12:43:09 +0000

But you admit that you had to provide an index hint to get the optimiser to use this misleading index, so what exactly are we proving here? Yes, there are (artificcial) situations where a single-row seek can require more effort than is apparent at first glance, but since the optimiser doesn’t actually choose such options unless you make it I’m not sure how surprising the information is here?

By: gbn

gbn — Thu, 16 Jun 2011 13:09:44 +0000

The optimiser has just found an index that matches roughly and decided to use it.
It isn’t really covering for this query, more "convenient".
So in that sense, yes, the seek is useless because it is a scan.

By: Rob Farley

Rob Farley — Thu, 16 Jun 2011 12:40:06 +0000

Hi gbn,
Yes, there are benefits to having the equality predicate’s field as the leading key. But that’s pretty much it. Even though the covering index looks good according to the plan, the fact that the Seek Predicate is so non-selective is a problem. I know there are better indexes available (the best being a filtered index), but I’m showing that just because you have a Seek on a Covering Index, you don’t necessarily have an effective index.
Rob

By: gbn

gbn — Thu, 16 Jun 2011 10:56:04 +0000

What if the index matches all WHERE conditions?
CREATE INDEX rf_ix_Covering ON Production.Product (DaysToManufacture, ReorderPoint, Color)
INCLUDE (Name, ProductNumber, Size)
WITH (FILLFACTOR=30)
or this with equality column first?
CREATE INDEX rf_ix_Covering ON Production.Product(Color, DaysToManufacture, ReorderPoint)
INCLUDE (Name, ProductNumber, Size)
WITH (FILLFACTOR=30)
The index above isn’t covering in the sense that I understand because filter/key columns don’t match the query. You are filtering unsorted INCLUDE columns

By: Rob Farley

Rob Farley — Mon, 23 May 2011 13:10:55 +0000

Oh, and Andrew – the other fillfactors were 100%, but as mentioned in the post, the filter index had only one row, so fillfactor isn’t going to be particularly relevant. I did admit to "a bit of trickery", after all (but only to demonstrate a valid point).