A quick question.

Creating a Clustered index after the non-clustered index, is it not necessary to rebuild the non-clustered index(es)?

– Mahesh

I have a query here. I have a big table having more than 300,000,000 rows.
This table is Partitioned on a date column.
It has a clustered index and a non clustered index. Both indexes have same columns.

Is this a good approach. Kindly suggest.

Query 1 should not have used index which is for second query as there is no change in that index or query1. Additionally, Query 1 is not even retrieving the column which is in nonclustered index. We created clustered index on column used in Query 1, so it should make Query 1 to use that clustered index but instead it is using nonclustered index which was already created and available to use earlier.

Explanation is quite confusing..can u re-write with some figures ?

what is the use of the statement ” ON [PRIMARY] ” there ??

you can get few more details about indexes here:

http://blog.sqlauthority.com/2007/04/23/sql-server-understanding-new-index-type-of-sql-server-2005-included-column-index-along-with-clustered-index-and-non-clustered-index/

Regards,
Pinal Dave

Can you let me know as to where can i find the detailed explanation of Index and its type,also the need to create index.As your explanation is pretty much good,i would like read those topics from your website.

Regards
Denison.s

When I inserted 1000 rows into table and I run the above query in that case

first query using 50% Index Seek and 50 % RID loop (i dont know what is this)..

And after creating clustered index it have same behavior as u said (100% from non clusters index seek)

Plz explore this for first case when we have many rows in table and only we have non clusterd index i .e contradicting what u said? ..

Thanks & Regards
Rahul Bhargava

First table is customer table having a primary Cust_id

2nd table is order table having Cust_id as reference key.

There is no primary key in 2nd table (order)

Please suggest me that which type of index is suitable on 2nd table (order) ?

I was going through this video. I found this video very helpful for performance tuning like where to create which type of index to get best performance. Its a free video. I strongly recommend you to watch this video.

http://wtv.watchtechvideos.com/topic121.html

~ IM.

For example
The table(z_menu) schema is as like the below
ID int (IDENTITY_INSERT is ON)
User_ID nvarchar
MENU_ID nvarchar

The sample data is as like the below.

1, ‘user_a’, ‘q1211′
2, ‘user_a’, ‘a1211′
3, ‘user_a’, ‘c1232′
4, ‘user_b’, ‘c1232′
5, ‘user_b’, ‘e2312′
6, ‘user_c’, ‘s3122′
7, ‘user_c’, ‘q1211′
8, ‘user_c’, ‘c1232′

I use only the query
for example
select * from z_menu where User_ID=’user_a’

You emphasize “clustered index key”.

In this case
If so.
do i create clustered index key (id,User_ID) ?
do i create index key(User_ID) ?
what is optimal index ?

please help me.

/* Create Sample Table */
SET Rowcount OFF
DECLARE @cntr int
SET @cntr=0

WHILE @cntr < 1000
BEGIN
INSERT INTO [dbo].[MyTable]
([ID],[First],[Second])
VALUES (@cntr, N’First’ + cast(@cntr as nchar), N’Second’ + cast(@cntr as nchar))
SET @cntr = @cntr+1
END

The results are very different from yours.
1) After the non-clustered index is created,
* For the SELECT Second… query an Index Seek is indeed performed on the WHERE clause. and it took 2% of the total query time.

* For the SELECT ID… query, SQL used an Index Seek and joined to a RID Lookup to find ID within the result set. This took 4% of the total query time.

–So the table scan was a factor of a small table size.

2) After adding a clustered index on ID,
* For the SELECT Second… query an Index Seek is again performed on the WHERE clause. and it took 2% of the total query time.

* For the SELECT ID… query, SQL also used only an Index Seek on First,Second. This took 2% of the total query time.

– Ivan Kotev was right that this creates a covering index.

If the table was larger, say 100 pages, it would choose the index seek since < 5 page reads for the seek and bookmark look-up is clearly better than 100 for the table scan.

This could be expanded upon to make a much larger article, but for a short, to-the-point, answer provided, this is very nice.