Wygląda na to, że masz optymalny plan uruchomienia zapytania. Trudno będzie to poprawić. Oto kilka obserwacji.
Kwerenda wykonuje skanowanie indeksu klastrowego w indeksie PK_States. Nie używa indeksu przestrzennego. Dzieje się tak, ponieważ optymalizator zapytań uważa, że lepiej będzie użyć indeksu klastrowego zamiast jakiegokolwiek innego indeksu. Czemu? Prawdopodobnie dlatego, że w tabeli Stany jest kilka wierszy (50 plus może kilka innych dla Waszyngtonu, Puerto Rico itp.).
SQL Server przechowuje i pobiera dane na stronach 8KB. Rozmiar wiersza (zobacz Szacowanie rozmiaru wiersza) dla operacji filtrowania to 8052 bajty, co oznacza, że na stronę przypada jeden wiersz i około 50 stron w całej tabeli. Plan zapytania szacuje, że przetworzy około 18 z tych wierszy (zobacz Szacowana liczba wierszy). Nie jest to znacząca liczba wierszy do przetworzenia. Moje wyjaśnienie nie dotyczy dodatkowych stron, które są częścią tabeli, ale chodzi o to, że liczba ta wynosi około 50, a nie 50 000 stron.
Wróćmy więc do tego, dlaczego używa indeksu PK_States zamiast indeksu SPATIAL_States_Boundry. Indeks klastrowy z definicji zawiera rzeczywiste dane tabeli. Indeks nieklastrowy wskazuje stronę, na której istnieją dane, więc jest więcej stron do pobrania. Tak więc indeks nieklastrowy staje się użyteczny tylko wtedy, gdy istnieją większe ilości danych.
Mogą istnieć rzeczy, które możesz zrobić, aby zmniejszyć liczbę procesów stron (np. użyć indeksu pokrywającego), ale Twoje bieżące zapytanie jest już dobrze zoptymalizowane i nie zobaczysz znacznej poprawy wydajności.
