Изглежда, че имате оптимален план за изпълнение на заявката. Ще бъде трудно да подобрим това. Ето някои наблюдения.
Заявката извършва сканиране на клъстерен индекс на индекса PK_States. Не използва пространствения индекс. Това е така, защото оптимизаторът на заявките смята, че ще бъде по-добре да използва клъстерирания индекс вместо всеки друг индекс. Защо? Вероятно защото има малко редове в таблицата за щатите (50 плюс може би няколко други за Вашингтон, Пуерто Рико и т.н.).
SQL Server съхранява и извлича данни на 8KB страници. Размерът на реда (вижте Оценка на размера на реда) за операцията на филтъра е 8052 байта, което означава, че има един ред на страница и около 50 страници в цялата таблица. Планът за заявка изчислява, че ще обработи около 18 от тези редове (вижте прогнозния брой редове). Това не е значителен брой редове за обработка. Моето обяснение не засяга допълнителните страници, които са част от таблицата, но въпросът е, че броят им е около 50, а не 50 000 страници.
И така, обратно към това защо използва индекса PK_States вместо индекса SPATIAL_States_Boundry. Клъстерираният индекс по дефиниция съдържа действителните данни за таблицата. Неклъстъриран индекс сочи към страницата, където съществуват данните, така че има повече страници за извличане. Така че неклъстърираният индекс става полезен само когато има по-големи количества данни.
Може да има неща, които можете да направите, за да намалите броя на процесите на страници (напр. да използвате покриващ индекс), но текущата ви заявка вече е добре оптимизирана и няма да видите много подобрение на производителността.
