This question already has answers here:
Closed 12 years ago.
Possible Duplicate:
What are the differences between a clustered and a non-clustered index?
What are the difference between clustered and a non-clustered index?
What are the differences between a clustered and a non-clustered index?
A clustered index is a special type of index that reorders the way records in the table are physically stored. Therefore table can have only one clustered index. The leaf nodes of a clustered index contain the data pages.
A non clustered index is a special type of index in which the logical order of the index does not match the physical stored order of the rows on disk. The leaf node of a non clustered index does not consist of the data pages. Instead, the leaf nodes contain index rows.
Related
I have a non clustered index on column 'a' that is primary key. then if I create another clustered index on the same column. it improve performance with huge margin like from 16 seconds to 2 seconds? can anyone explain how this thing is happening ?
if I don't add new index and just convert the non clustered index that we have to clustered index then there is no improvement. how this is going on?
can't show code sorry!!!
today I went to a job interview and while I was there I heard that "Indexes are bascially a clones of the tables, on which they're made".
Could someone relate to this statement? Honestly I've never heard this kind of Index definition
Not really, although they could be.
Every index (including the clustered index) will be using the index keys in all of its internal nodes. What's different is what happens when we reach the leaves of the index.
In a normal, old-school non-clustered index in SQL Server, what you'll find in the leaves are the key values for the clustered index (or some form of row ID for heap tables). Whereas in the clustered index, you'll find the values for all columns, not just those which are the clustered keys and (for that index) it's specific keys.
INCLUDE in indexes muddies the water somewhat by including extra columns at the leaf level in non-clustered indexes.
If the total set of columns in (index keys, clustered-index keys, included columns) for a non-clustered index is the same as the set of all columns in the table, then to an extent the non-clustered index does seem to be a copy of the table - at least to the extent that any query making use of this index will not have to perform any table-lookups to retrieve all data.
If the set of columns above isn't the same as the set of all columns in the table then it's not a copy of the table. It's a copy of a subset of columns of the table. Of course, if this subset of columns are all of the columns required by a particular query then a table lookup can still be avoided.
If you spoke about a clustered index then it's true. Just check documentation:
Clustered indexes sort and store the data rows in the table or view
based on their key values. These are the columns included in the index
definition. There can be only one clustered index per table, because
the data rows themselves can be stored in only one order.
The only time the data rows in a table are stored in sorted order is
when the table contains a clustered index. When a table has a
clustered index, the table is called a clustered table. If a table has
no clustered index, its data rows are stored in an unordered structure
called a heap.
But if you spoke about non-clustered index then it's false coz table store as a heap and index separate from table. In this case index is another object which looks like a data structure.
Nonclustered indexes have a structure separate from the data rows. A
nonclustered index contains the nonclustered index key values and each
key value entry has a pointer to the data row that contains the key
value.
The pointer from an index row in a nonclustered index to a data row is
called a row locator. The structure of the row locator depends on
whether the data pages are stored in a heap or a clustered table. For
a heap, a row locator is a pointer to the row. For a clustered table,
the row locator is the clustered index key.
You can add nonkey columns to the leaf level of the nonclustered index
to by-pass existing index key limits, and execute fully covered,
indexed, queries. For more information, see Create Indexes with
Included Columns. For details about index key limits see Maximum
Capacity Specifications for SQL Server.
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.
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.
So I have this structure on a user table:
But if I run the following code:
select count(*)
from WH.dbo.tb_DimUserAccount
It seems to go for the Non-Unique Non-Clustered index ix_DimUserAccount_UserType:
This is the Index Scan:
Why doesn't it go for a scan of ix_DimUserAccount_Unique ? Should I change my code to somehow use a different index?
Because the non clustered index is probably narrower than the clustered index and it is cheaper to scan than the clustered index (fewer pages to read).
The NCI leaf pages just contain values for the index keys and any included columns. The clustered index leaf pages need to contain values (or pointers to the values) for all columns in the table.
Thus the clustered index will (assuming equal fill factors) generally fit fewer rows per page than an NCI (except for the case where an NCI includes all columns in the table)
i have got a table (stores data of forum, means normally no edit and update just insert) on which i have a primary key column which is as we know a clustered index.
please tell me, will i get any advantage if i creates a non-clustered index on that column (primary key column)?
EDIT: my table has got currently around 60000 records, what will be better to place non-clustered index on it or create a same new table and create index and then copy records from old to new table.
Thanks
Every table should have a clustered index
Non-clustered indexes allow INCLUDEs which is very useful
Non-clustered indexes allow filtering in SQL Server 2008+
Notes:
Primary key is a constraint which happens to be a clustered index by default
One clustered index only, many non-clustered indexes
One advantage: you can INCLUDE other columns in the index.
A clustered index specifies the physical storage order of the table data (this is why there can only be one clustered index per table).
If there is no clustered index, inserts will typically be faster since the data doesn't have to be stored in a specific order but can just be appended at the end of the table.
On the other hand, index searches on the key column will typically be slower, since the searches cannot use the advantages of the clustered index.
The only possible advantage that I can see could be from the fact that the entries on leaf pages of nonclustered index are not as wide. They only contain index columns while the clustered index' leaf pages are the actual rows of data. Therefore, if you need something like select count(your_column_name) from your_table then scanning the nonclustered index will involve considerably smaller number of data pages. Or if the number of index columns is greater than one and you run any query which does not need data from non-indexed columns then again, nonclustered index scan will be faster.