Запрос на замедление пространственного индекса

Исходная информация

У меня есть таблица, содержащая ПОЛИГОНЫ/МУЛЬТИПОЛИГОНЫ, представляющие территории клиентов:

• Таблица содержит примерно 8 000 строк
• Приблизительно 90% полигонов представляют собой круги
• Остальные полигоны представляют один или несколько штатов, провинций или других географических регионов. Необработанные полигональные данные для этих фигур были импортированы из данных переписи населения США.
• Таблица имеет пространственный индекс и кластеризованный индекс по первичному ключу. Никаких изменений в параметры SQL Server 2008 R2 по умолчанию не вносилось. 16 ячеек на объект, все уровни средние.

Вот упрощенный запрос, который воспроизведет проблему, с которой я сталкиваюсь:

DECLARE @point GEOGRAPHY = GEOGRAPHY::STGeomFromText('POINT (-76.992188 39.639538)', 4326)

SELECT terr_offc_id
FROM tbl_office_territories
WHERE terr_territory.STIntersects(@point) = 1

То, что кажется простым, прямым запросом, выполняется за 12 или 13 секунд и имеет очень сложный план выполнения для такого простой запрос.

В ходе моего исследования несколько источников предложили добавить в запрос подсказку индекса, чтобы убедиться, что оптимизатор запросов правильно использует пространственный индекс. Добавление WITH(INDEX(idx_terr_territory))не имеет никакого эффекта, и из плана выполнения ясно, что он ссылается на мой индекс независимо от подсказки.

Сокращение полигонов

Казалось возможным, что полигоны территорий, импортированные из данных переписи населения США, излишне сложны, поэтому я создал второй столбец и протестировал уменьшенные полигоны (с методом Reduce()) с разной степенью толерантности.Выполнение того же запроса, что и выше, для нового столбца дало следующие результаты:

• Без сокращения: 12649 мс
• Уменьшено на 10: 7194 мс
• Уменьшено на 20: 6077 мс
• Уменьшено на 30: 4793 мс
• Уменьшено на 40: 4397 мс
• Уменьшено на 50: 4290 мс

Явно движется в правильном направлении, но снижение точности кажется неэлегантным решением. Разве не для этого должны быть индексы? И план выполнения по-прежнему кажется странно сложным для такого простого запроса.

Пространственный индекс

Из любопытства я удалил пространственный индекс и был ошеломлен результатами:

1. Запросы выполнялись быстрее БЕЗ индекса (менее 3 сек. без сокращения, менее 1 сек. с допуском сокращения > = 30)
2. План выполнения выглядел намного проще:

Мои вопросы

1. Почему мой пространственный индекс замедляет работу?
2. Действительно ли необходимо уменьшить сложность моего полигона, чтобы ускорить мой запрос? Снижение точности может вызвать проблемы в будущем, и не похоже, что это будет очень хорошо масштабироваться.

Другие примечания

• SQL Server 2008 R2 с пакетом обновления 1 (SP1) был применен
• Дальнейшие исследования показаливыполнение запроса внутри хранимой процедуры. Попробовал это, и ничего не изменилось.