Why is this an Index Scan and not a Index Seek?

Question

Here\'s the query:

SELECT      top 100 a.LocationId, b.SearchQuery, b.SearchRank
FROM        dbo.Locations a
INNER JOIN  dbo.LocationCache b ON a.LocationId          


        

Answer 1

Have you tried to update your statistics?

UPDATE STATISTICS dbo.LocationCache

Here are a couple of good references on what that does and why the query optimizer will choose a scan over a seek.

http://social.msdn.microsoft.com/Forums/en-CA/sqldatabaseengine/thread/82f49db8-0c77-4bce-b26c-1ad0a4af693b

Summary

There are several things to take into consideration here. Firstly, when SQL decides upon the best (good enough) plan to use, it looks at the query, and then also looks at the statistics that it stores about the tables involved.

It then decides if it is more efficient to seek down the index, or scan the whole leaf level of the index (in this case, it involves touching every page in the table, because it is a clustered index) It does this by looking at a number of things. Firstly, it guesses how many rows/pages it will need to scan. This is called the tipping point, and is a lower percentage than you may think. See this great Kimberly Tripp blog http://www.sqlskills.com/BLOGS/KIMBERLY/category/The-Tipping-Point.aspx

If you are within the limits for the tipping point, it may be because your statistics are out of date, or your index is heavily fragmented.

It is possible to force SQL to seek an index by using the FORCESEEK query hint, but please use this with caution, as generally, providing you keep everything weel maintained, SQL is pretty good at deciding what the most efficient plan will be!!