Det her er ikke rigtigt.
Jeg har to muligheder:
1) Statistik er forældet på tabellerne. Genopbyg indekser og opdater statistik.
2) Som du sagde, er geografi-tabelposter store, der strækker sig over mange sider (ikke den ene post, der spænder over flere sider, da den ikke kan, men posten er tæt på 8K-mærket). I dette tilfælde kan det sjovt nok hjælpe at oprette endnu et ikke-klynget indeks på det klyngede indeks.
OPDATERING
Jeg er glad for, at det har virket. Nu lidt forklaring.
Først og fremmest, hvis noget ikke er rigtigt, og eksekveringsplanen ser mærkelig ud, skal du altid se på statistikker og genopbygge indekser.
Oprettelse af et ikke-klynget indeks for det klyngede indeks bør normalt ikke give nogen fordel, men når tabellen har mange poster, og posten er tæt på sin 8K-grænse, er det nyttigt. Som du ved, indlæser SQL en 8K-side, når den går til disken for at indlæse en post. På lignende måde vil det indlæse en 8K-side ved at gå til indekser. Nu, hvor indeks er et 4-byte heltal, betyder det, at det indlæser ID for 2000 poster, mens det vil indlæse en håndfuld poster, hvis det bruger klynget indeks (husk, at alt, hvad vi behøver, er ID'et til JOIN-bitten). Nu da dette er en binær søgning, forventer jeg ikke, at det kun vil hjælpe en smule. Så måske er der noget andet, der ikke er helt rigtigt, men svært at gætte, når man ikke har set systemet.