SQL Server: Why Clustered Index Scan and not Table Scan? - sql

Question

I have following table schema -
CREATE TABLE [dbo].[TEST_TABLE]
(
[TEST_TABLE_ID] [int] IDENTITY(1,1) NOT NULL,
[NAME] [varchar](40) NULL,
CONSTRAINT [PK_TEST_TABLE] PRIMARY KEY CLUSTERED
(
[TEST_TABLE_ID] ASC
)
)
I have inserted huge data in TEST_TABLE.
As I have marked TEST_TABLE_ID column as primary key, clustered index will be created on TEST_TABLE_ID.
When I am running following query, execution plan is showing Clustered Index Scan which is expected.
SELECT * FROM TEST_TABLE WHERE TEST_TABLE_ID = 34
But, when I am running following query I was expecting Table Scan as NAME column does not have any index:
SELECT * FROM TEST_TABLE WHERE NAME LIKE 'a%'
But in execution plan it is showing Clustered Index Scan.
As NAME column does not have any index why it is accessing the clustered index?
I believe, this is happening as clustered index resides on data pages.
Can anyone tell me if my assumption is correct? Or is there any other reason?

Answer 1

A clustered index is the index that stores all the table data. So a table scan is the same as a clustered index scan.
In a table without a clustered index (a "heap"), a table scan requires crawling through all data pages. That is what the query optimizer calls a "table scan".

Answer 2

As others explained already, for a table that has a clustered index, a Clustered Index Scan means a Table Scan.
In other words, the table is the clustered index.
What you have wrong is your first query execution plan:
SELECT *
FROM TEST_TABLE
WHERE TEST_TABLE_ID = 34 ;
It does a Clustered Index Seek and not a Scan. It doesn't have to search (scan) the whole table (clustered index), it goes directly to the point (seeks) and checks if a row with id=34 exists.
You can see a simple test in SQL-Fiddle, and how the two execution plans differ.

Answer 3

The table is stored as a clustered index. The only way to scan the table is to scan the clustered index. Only tables with no clustered index can have a "table scan" per se.

Answer 4

It is because this table has a clustered index and it will scan the entire clustered index to return all the rows base on the where clause. How ever you should be seeing a missing index message.

Answer 5

When you build a Clustered Index on a table, then SQL Server logically orders the rows of that table based on the Clustered Index Key, which in your case is Test_Table_ID.
However, when you see the Clustered Index Scan operator, this COULD be a little misleading. If certain conditions are met, (which equate to SQL Server not caring about the order of the data) then SQL Server is still able to perform an unordered allocation scan, which is more similar to a table scan than an clustered index scan, as it actually reads the leaf level of the CI (the tables data pages) in allocation order, based on the IAM chain, as opposed to following the pointers in the index. This can potentially give you a performance improvement, as fragmentation (pages being out of physical order) does not decrease performance
To see if this is happening, look at the Ordered property in the execution plan. If this is set to False, then you have an unordered allocation scan.