sql server - Why does this Sql Statement (with 2 table joins) takes 5 mins to complete? -


updates : 3 updates added below

the following sql statement takes 5 mins complete. i. just. don't. get. :( first table has 6861534 rows in it. second table has little bit less .. , third table (which contains 4 geography fields) has same first.

those geography fields in 3rd table .. shouldn't messin' sql statement ... should it? because table large (due geography fields) has huge page sizes or .. destroying table scan count does?

select count(*) [dbo].[locations]     inner join [dbo].[myusalocations] b on a.locationid = b.locationid     inner join [dbo].[geographyboundaries] c on a.locationid = c.locationid 

alt text

alt text

alt text

alt text

update

as requested, here's more info geographyboundaries table... alt text

/****** object:  index [pk_geographyboundaries]    script date: 11/16/2010 12:42:36 ******/ alter table [dbo].[geographyboundaries] add  constraint [pk_geographyboundaries] primary key clustered  (     [locationid] asc )with (pad_index  = off, statistics_norecompute  = off, sort_in_tempdb = off, ignore_dup_key = off, online = off, allow_row_locks  = on, allow_page_locks  = on) on [primary] go 

update #2 - after adding non-clustered index

after adding non-clustered index, it's dropped down 4 seconds! awesome. why ?

alt text

what zee frak?

update 3 - more interesting , confusing info!

now, when 1 join , force index .. goes 5 mins. did to

  • make sure myusalocations table wasn't screwing things around joins.
  • make sure pk doing weird things.

.

select count(*) [dbo].[locations]          inner join [dbo].[geographyboundaries] c             (index(pk_geographyboundaries)) on a.locationid = c.locationid 

this ain't right.

i have 2 possibilities:

1) statistics out of date on tables. rebuild indexes , update stats.

2) said, geography table records big spanning many pages (not 1 record spanning multiple pages since can't record close 8k mark). in case, funny enough, creating non-clustered index on clustered index might help.

update

i pleased has worked. explanation.

first of all, if not right , execution plan looks weird, looks @ statistics , rebuild indexes.

creating non-clustered index clustered index should not provide benefit when table has many records , record close 8k limit, helpful. know, sql when goes disk load record, loads 8k page. in similar way going indexes load 8k page. index being 4-byte integer means loading id 2000 records while going load handful records if uses clustered index (bear in mind need id join bit). being binary search, don't expect hugely bit. perhaps else not quite right, difficult guess not having seen system.


Comments

Popular posts from this blog

android - Spacing between the stars of a rating bar? -

html - Instapaper-like algorithm -

c# - How to execute a particular part of code asynchronously in a class -