|
|
|
Hall of Fame
       
Group: General Forum Members
Last Login: Friday, March 15, 2013 2:43 PM
Points: 3,924,
Visits: 1,554
|
|
Thanks for the article, Gail.
"When an index scan is done on the clustered index, it’s a table scan in all but name."
Then why do we see index scan and table scan separately in execution plan rather just table scan on a single query with simple join?
Would wait for part 2 and 3.
SQL DBA.
|
|
|
|
|
Hall of Fame
       
Group: General Forum Members
Last Login: Today @ 8:50 AM
Points: 3,572,
Visits: 5,106
|
|
SanjayAttray (10/26/2009) Thanks for the article, Gail.
"When an index scan is done on the clustered index, it’s a table scan in all but name."
Then why do we see index scan and table scan separately in execution plan rather just table scan on a single query with simple join?
Would wait for part 2 and 3.
I don't follow that one Sanjay. Can you post a plan with what you are meaning and what the issue with that plan is?
Best,
Kevin G. Boles SQL Server Consultant SQL MVP 2007-2012 TheSQLGuru at GMail
|
|
|
|
|
Grasshopper
      
Group: General Forum Members
Last Login: Tuesday, July 03, 2012 6:26 AM
Points: 12,
Visits: 204
|
|
Thanks Gail! This has helped my understanding on this topic. I have posted the article on an internal wikipedia as my Manager was very interested in the topic as well. This was very well written and I look forward to the next parts. Thanks again! Rob
|
|
|
|
|
SSC-Dedicated
           
Group: General Forum Members
Last Login: Today @ 12:59 PM
Points: 37,640,
Visits: 29,895
|
|
SanjayAttray (10/26/2009) "When an index scan is done on the clustered index, it’s a table scan in all but name."
Then why do we see index scan and table scan separately in execution plan rather just table scan on a single query with simple join?
Possibly because they're against different indexes or different tables?
What I'm saying there is that a clustered index scan is virtually the same as a table scan. You won't see the table scan operation against a table that has a clustered index. It appears in the execution plan as a clustered index scan. That doesn't make it any more efficient than a table scan.
Gail Shaw Microsoft Certified Master: SQL Server 2008, MVP SQL In The Wild: Discussions on DB performance with occasional diversions into recoverability
We walk in the dark places no others will enter We stand on the bridge and no one may pass
|
|
|
|
|
Right there with Babe
      
Group: General Forum Members
Last Login: Yesterday @ 9:18 AM
Points: 772,
Visits: 1,825
|
|
Excellent article. This coupled with Brad's article is very helpful in design considerations. I was especially looking for the size of the row pointer. It's quite a consideration for the choice of a clustered key. For example If I don't have a clustered index I get 8 byte pointers. If I used an INTEGER row ID (auto number) I get 4 byte pointers. If I use a US phone number as my clustered key I get 10 byte pointers. (I use data compression techniques).
You said:Sure, hard drives are cheap and storage is abundant but increasing the size of a database has other effects, But that is not so true for those of us working on the Mobile. Every byte is precious.
I'm looking forward to the other installments.
ATB
Charles Kincaid
|
|
|
|
|
SSC-Enthusiastic
      
Group: General Forum Members
Last Login: Friday, June 08, 2012 12:30 AM
Points: 150,
Visits: 3,892
|
|
| I agree, excellent article Gail. I'll also be looking for the follow-up articles. -Carleton
|
|
|
|
|
Ten Centuries
      
Group: General Forum Members
Last Login: Today @ 1:05 PM
Points: 1,408,
Visits: 4,505
|
|
|
|
|
|
SSC Rookie
      
Group: General Forum Members
Last Login: Monday, October 25, 2010 6:40 AM
Points: 46,
Visits: 133
|
|
| Thanks, Gail. Excellent nuts and bolts foundation. Perhaps you could cover statistics one day and how they relate to indexes.
|
|
|
|
|
Hall of Fame
       
Group: General Forum Members
Last Login: Today @ 8:50 AM
Points: 3,572,
Visits: 5,106
|
|
Carleton (10/26/2009) I agree, excellent article Gail. I'll also be looking for the follow-up articles. -Carleton
I believe this is somewhat dependent on the index and pages therein, but it has been shown here on sqlservercentral.com that the percentage is VERY low, typically on the order of 1% or so of the total rows.
Best,
Kevin G. Boles SQL Server Consultant SQL MVP 2007-2012 TheSQLGuru at GMail
|
|
|
|
|
SSC-Dedicated
           
Group: General Forum Members
Last Login: Today @ 12:59 PM
Points: 37,640,
Visits: 29,895
|
|
SQL Noob (10/26/2009) is there any hard documentation on what the tipping point is for an index seek to become an index scan? is it 5% of rows affected, 10% or some other percentage?
It usually tips somewhere between 0.5%-1%. It's not a hard-coded value, it depends on a whole bunch of factors, but it is a very, very low percentage. This is covered in either part 2 or 3, there's also a post on my blog - http://sqlinthewild.co.za/index.php/2009/01/09/seek-or-scan/
Gail Shaw Microsoft Certified Master: SQL Server 2008, MVP SQL In The Wild: Discussions on DB performance with occasional diversions into recoverability
We walk in the dark places no others will enter We stand on the bridge and no one may pass
|
|
|
|