Dit klopt niet.
Ik heb twee mogelijkheden:
1) Statistieken zijn verouderd op de tabellen. Herbouw indexen en update statistieken.
2) Zoals u zei, zijn aardrijkskundetabelrecords groot en beslaan vele pagina's (niet dat ene record dat meerdere pagina's beslaat, aangezien het niet kan, maar het record ligt dicht bij de 8K). In dit geval, grappig genoeg, kan het helpen om nog een niet-geclusterde index op de geclusterde index te maken.
UPDATE
Ik ben blij dat het is gelukt. Nu wat uitleg.
Allereerst, als er iets niet klopt en het uitvoeringsplan ziet er raar uit, kijkt altijd naar statistieken en herbouwt indexen.
Het maken van een niet-geclusterde index voor de geclusterde index zou normaal gesproken geen enkel voordeel moeten opleveren, maar wanneer de tabel veel records heeft en de record dicht bij de 8K-limiet ligt, is het handig. Zoals u weet, laadt SQL, wanneer het naar de schijf gaat om een record te laden, een 8K-pagina. Op een vergelijkbare manier naar indexen zal het een 8K-pagina laden. Nu index een geheel getal van 4 bytes is, betekent dit dat het ID voor 2000 records wordt geladen, terwijl het een handvol records gaat laden als het een geclusterde index gebruikt (houd er rekening mee dat we alleen de ID voor het JOIN-bit nodig hebben). Nu dit een binaire zoekopdracht is, verwacht ik niet dat het enorm zal helpen, maar een beetje. Dus misschien is er iets anders niet helemaal goed, maar moeilijk te raden als je het systeem niet hebt gezien.