Why is my query doing a clustered index scan when it has an index

Question

I am running a sample database from a SQL Server 2012 training book, learning a bit about indexes so I thought I'd try and see how it works.

The table Orders has an index on shippostalcode, so I tried to put that in the where clause, I know there are 850+ records in that table, and this code is split well like:

10328
10195
10342
10318
10196
10139
10294
10354
10199
10157
10137
10258
10274
10286
10158
10167
10329
10351

So when I do this, why do I get a clustered index scan, which I read is the same as a table scan which is sub-optimal?

EDIT:

I did :

SELECT [orderid] 
      ,[shippostalcode]
  FROM [TSQL2012].[Sales].[Orders]
  WHERE shippostalcode = '10307'

Which gave me an index seek. Which leads me to think (from the little I learnt) that SQL Server may think that a scan is faster than doing a bookmark lookup for the rest of the columns?

EDIT 2:

After reading about the tipping point here : http://www.sqlskills.com/blogs/kimberly/why-arent-those-nonclustered-indexes-being-used/

It says its around 30%. I used the query from here to get the total pages in my table :

Determining page count on each SQL table without using DBCC

I get 49 used and 53 reserved. So 30% of 49 = 14.7 * 17 (each page stores this much) is about 250 rows. But my query was only returning 9 so it was no where near the tipping point.

Answer 1

I have figured it out, as mentioned in some articles I read the selectivity has to be under 1%. I was mislead by an article about the tipping points thinking it would only go into scan mode if it was returning 30%+

But actual testing shows that anything returning 6+ rows is a scan, and anything less is a seek.

So if it returns about 0.5% it will do a seek, else a scan. 0.5% of my 830 rows is 4.15 rows.

Hope this helps someone.