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

In Short: You do not have filter on LocationCache, the whole table content should be returned. You have a fully covering index. Index SCAN (once) is the cheapest operation, and query optimizer picks it.

To optimize: You are joining the whole tables, and later get only top 100 results. I dunno how big are they, but try to subquery the [Locations] table CountryId, Type and then join just the result with [LocationCache]. Will be waaaay faster if you have more than 1000 rows there. Also, try adding some more restrictive filters before joins if possible.

Index Scan: Since a scan touches every row in the table whether or not it qualifies, the cost is proportional to the total number of rows in the table. Thus, a scan is an efficient strategy if the table is small or if most of the rows qualify for the predicate.

Index Seek: Since a seek only touches rows that qualify and pages that contain these qualifying rows, the cost is proportional to the number of qualifying rows and pages rather than to the total number of rows in the table.

If there is an index on a table, and if the query is touching a larger amount of data, which means the query is retrieving more than 50 percent or 90 percent of the data, and then optimizer would just scan all the data pages to retrieve the data rows.

source