SQL Server Creating Index over Index [closed] - sql

Question

Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 8 years ago.
Improve this question
Just wanted to know what happens internally in SQL Server when we create,
Non Clustered over a Clustered Index.
Clustered Index over Non Clustered Index.
Non Clustered Index Over Non Clustered Index.
Please comment.

Answer 1

For all of the execution plans I have used the same base table filled with meaningless data:
CREATE TABLE dbo.T (ID INT NOT NULL, Filler CHAR(200) NULL);
INSERT dbo.T (ID, Filler)
SELECT ROW_NUMBER() OVER(ORDER BY Object_ID),
CAST(NULLIF(ABS(Object_ID) % 10, 0) AS CHAR(200))
FROM sys.all_objects
1. What happens internally in SQL Server when we create a Non Clustered over a Clustered Index.
This is just a normal create index process, so sorts the data in the manor specified and creates the relevant nodes up from the leaf nodes. The leaf node will store a "pointer" back to the clustered index to allow for key lookups.
So once the clustered index is in place on dbo.T (ID) the execute plan for creating the non-clustered index shows the sort:
And hovering over the sort shows that it is ordering by Filler, then adding it's own sort to ensure the sort is deterministic:
2. What happens internally in SQL Server when we create a Clustered Index over Non Clustered Index.
I think to explain this properly I need to explain how a clustered index on a table with no clustered index would work. A table with no clustered index is called a "Heap" table, this just means that the data is stored in no specific order and is usually just stored in the order it is inserted in. Essentailly SQL Server builds its own clustered index clustered on an internal column RowID, however without the constraints of an explicit clustered index it is free to move the data around if and when it sees fit (More reading on Forwarding records), the non-clustered index will then store a the rowID at the leaf level so it has a way of performing lookups.
When you then create a clustered index on a heap table the table has to be rebuilt, ordering by the columns you have specified, this means that all indexes are also dropped and rebuilt. to show this I first added the non clustered index to dbo.T:
CREATE NONCLUSTERED INDEX IX_T_Filler ON dbo.T (Filler);
Unlike above you can see that a table scan is done as there is no clustered index to use, and the sort done when creating the index does not include the ID column as it did above:
Then afterwards add the clustered index:
CREATE CLUSTERED INDEX IX_T_ID ON dbo.T (ID);
You can see in the execution plan that the nonclustered index is also rebuilt so the leaf will point to the new clustered index rather than the row ID as it did previously. (Note the second query is the same as in the first part when the nonclustered index was built on the clustered index)
3. What happens internally in SQL Server when we create a Non Clustered Index Over Non Clustered Index.
Nonclustered indexes are completely independent of each other, so this is the same as 1 (or the first part of 2 if there is no clustered key), i.e. It does not matter how many non clustered indexes already exist, the method of creating a new one remains the same.