To nie w porządku.
Mam dwie możliwości:
1) Statystyki są nieaktualne w tabelach. Odbuduj indeksy i zaktualizuj statystyki.
2) Jak powiedziałeś, rekordy tabeli Geografia są duże i obejmują wiele stron (nie ten jeden rekord obejmujący wiele stron, ponieważ nie może, ale rekord jest zbliżony do znaku 8K). W tym przypadku, dość zabawne, może pomóc utworzenie innego indeksu nieklastrowego na indeksie klastrowym.
AKTUALIZUJ
Cieszę się, że się udało. Teraz kilka wyjaśnień.
Po pierwsze, jeśli coś jest nie tak, a plan wykonania wygląda dziwnie, zawsze sprawdzaj statystyki i odbuduj indeksy.
Tworzenie indeksu nieklastrowego dla indeksu klastrowego zwykle nie powinno przynieść żadnych korzyści, ale gdy tabela zawiera wiele rekordów, a rekord jest bliski limitu 8K, jest to pomocne. Jak wiecie, SQL, gdy idzie na dysk, aby załadować rekord, ładuje stronę o rozmiarze 8K. W podobny sposób, przechodząc do indeksów, załaduje stronę 8K. Teraz, gdy indeks jest 4-bajtową liczbą całkowitą, oznacza to ładowanie identyfikatora 2000 rekordów, podczas gdy będzie ładował kilka rekordów, jeśli używa indeksu klastrowego (pamiętaj, że potrzebujemy tylko identyfikatora dla bitu JOIN). Teraz, gdy jest to wyszukiwanie binarne, nie oczekuję, że pomoże tylko trochę. Więc może coś innego jest nie tak, ale trudno odgadnąć, nie widząc systemu.
