Table Scan, Index Scan, Index Seek

A table scan is where the table is processed row by
row from beginning to end.

An index scan is where the index is processed row by
row from beginning to end.

If the index is a clustered index then an index scan is really a
table scan.

When you see an index scan on a clustered index that is actually a table
scan; since the root of the clustered index is the table.

Scan means it has to run the entire
object, seeks will make specific hits into the index/table.

What is the difference between a table and index scan in an execution
plan?

Question

When I create a graphical query execution plan of a query, I notice that
there are two types of scans: Table Scans and Index Scans. How are these
different?

Answer

When the Query Optimizer is asked to optimize
a query and create an execution plan for it, it tries its best to use an Index
Seek. An Index Seek means that the Query Optimizer was able to find a useful
index in order to locate the appropriate records. As you probably know, indexes
make data retrieval in SQL Server very fast.

But when the Query Optimizer is not able to perform an Index Seek, either
because there is no indexes or no useful indexes available, then SQL Server has
to scan all the records, looking for all the records that meet the requirements
of the query.

There are two types of scans the SQL Server can perform. When a Table Scan is
performed, all the records in a table are examined, one by one. For large
tables, this can take a long time. But for very small tables, a table
scan can actually be faster than an Index Seek. So if you see that SQL
Server has performed a Table Scan, take a note of how many rows are in the
table. If there aren't many, then in this case, a Table Scan is a good thing.

When an Index Scan is performed, all the rows in the leaf level of the index
are scanned. What does this mean? Essentially, this means that all of the rows
of the table or the index are examined instead of the table directly. Sometimes,
the Query Optimizer determines that an Index Scan is more efficient than a Table
Scan, so one is performed, although the performance difference between them is
generally not much.

You might ask that if there is an index available, why can't an Index Seek be
performed? In some cases, such as if a huge quantity of rows need to be
returned, it is faster to do an Index Scan than an Index Seek. Or it
may be because the index is not selective enough. In any case, the Query
Optimizer doesn't think the available index is useful, other than for performing
an Index Scan.

So what does all this mean from an analysis standpoint? Generally speaking,
an Index Scan or an Index Seek is almost the same thing, from a performance
perspective. If you see any one of these in a query execution plan, the
first thing you need to do is to see if there are few rows in the table. If so,
then a scan is OK. Or, if many rows are being returned, then a scan is often
faster than an Index Seek, and the Query Optimizer made the correct choice of
selecting a scan. The only way to speed up this particular situation
would be to find a way to rewrite the query in order to return fewer rows,
assuming this is possible.

If the above two reasons don't apply, then your next step would be to try to
identify useable indexes to help speed the performance of the query, assuming
that the current performance of the query is unacceptable, so that an Index Seek
is performed instead of an Index or Table Scan.