|
|
|
SSC-Enthusiastic
 
Group: General Forum Members
Last Login: Wednesday, March 17, 2010 8:23 AM
Points: 179,
Visits: 393
|
|
I figured an indexing question would best be answered by folks who focus on performance tuning, if there was a better forum for this please let me know.
Anyway I was looking at: http://msdn.microsoft.com/en-us/library/ms177484(SQL.90).aspx and an article talking about indexing.
With included columns you can add them to a NONclustered index so that when a query uses that index additional columns the query SELECTs can be "included columns" and returned as part of the INDEX SEEK instead of having to hop over to the table, lookup the table row, and then scan that row of the table to get whatever columns are needed.
Classic example:
nonclustered index on: FirstName, LastName.
included columns: EmailAddress, PhoneNumber
The table would also of course have a PK which is part of the clustered index.
The clustered index might have other columns, maybe LastName or "whatever".
It sorts the table and is used to quickly locate records.
Here is what I don't get:
I do my query: SELECT FirstName, LastName, EmailAddress, PhoneNumber
FROM table
WHERE FirstName = 'John' AND LastName = 'Doe'
It then uses my NONclustered index to perform my query AND it would then locate the record(s) that match my criteria.
What happens then?
It looks like it would then have a pointer to the clustered index which it would use to locate the record in the table, and retrieve the data.
Except in this case it is a COVERING INDEX... and it has Email and Phone stored in the NONclustered index's leaf level.
So... what does it do?
Does it grab Email and Phone and THEN still jump to the clustered index to locate the row in the table so it can pull out First and Last Name?
What I'm getting at is this:
CLUSTERED indexes store the actual table at their leaf level, is that correct?
NONclustered stores pointers to the clustered index (the table) or to artificial keys in a heap (tables with no clustered index), right?
So... how does the included column on a NONclustered index allow the query to avoid having to lookup the data in the table itself?
That's the part I don't get.
It seems like it grabs Phone and Email from its leaf level, but still has to jump to the clustered index to get the Fname and Lname since it doesn't actually store those data values in the index, just pointers to them...
So what am I not following/understanding?
Thanks!
|
|
|
|
|
SSCertifiable
Group: General Forum Members
Last Login: Yesterday @ 11:56 PM
Points: 7,395,
Visits: 15,222
|
|
The columns defined in the INCLUDE statement are stored at the leaf level of the non-clustered index. There's no need to go to the cluster or a heap to retrieve the data. Storing the data increases the size of the index, but it doesn't change the size and levels of the B-Tree since the index keys are still the same. That means, for the most part, the index seek operations should be as fast as ever.
----------------------------------------------------
"The credit belongs to the man who is actually in the arena, whose face is marred by dust and sweat and blood..." Theodore Roosevelt
The Scary DBA
Author of SQL Server 2008 Query Performance Tuning Distilled
For better & quicker help read:
How to Post Performance Problems
|
|
|
|
|
SSChampion
Group: General Forum Members
Last Login: Yesterday @ 11:06 AM
Points: 17,125,
Visits: 12,226
|
|
Maxer (10/1/2008)
It seems like it grabs Phone and Email from its leaf level, but still has to jump to the clustered index to get the Fname and Lname since it doesn't actually store those data values in the index, just pointers to them...
FName and LName are the index keys, so they are stored at all levels of the index. They have to be, how else would SQL be able seek on those columns.
In a nonclustered index, the nonclustered index keys and the clustered index keys are stored at all levels of the index. The include columns are only stored at the leaf level. The clustering keys are there as a 'pointer' to the row, in case a bookmark lookup is required.
Gail Shaw
We walk in the dark places no others will enter
We stand on the bridge and none may pass
|
|
|
|
|
SSC-Enthusiastic
Group: General Forum Members
Last Login: Wednesday, March 17, 2010 8:23 AM
Points: 179,
Visits: 393
|
|
GilaMonster (10/1/2008)
Maxer (10/1/2008)
It seems like it grabs Phone and Email from its leaf level, but still has to jump to the clustered index to get the Fname and Lname since it doesn't actually store those data values in the index, just pointers to them...
FName and LName are the index keys, so they are stored at all levels of the index. They have to be, how else would SQL be able seek on those columns.In a nonclustered index, the nonclustered index keys and the clustered index keys are stored at all levels of the index. The include columns are only stored at the leaf level. The clustering keys are there as a 'pointer' to the row, in case a bookmark lookup is required.
Ah, of course. Indeed otherwise how would it be able to seek on those columns :)
Well that explains that.
Thanks for pointing out my obvious logical error there. I knew I was failing to take something into account, and that would certainly be it!
|
|
|
|
