Пространственный индекс, замедляющий запрос - PullRequest
Новая
       37

Пространственный индекс, замедляющий запрос

6 голосов
/ 14 марта 2012

Фон

У меня есть таблица, содержащая полигоны / мультиполигоны, которые представляют территории клиентов:

  • Таблица содержит примерно 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 секунд, и у него, как представляется, очень сложный план выполнения для такого простого запроса.

Execution Plan

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

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

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

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

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

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

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

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

Execution Plan w/o index

Мои вопросы

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

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

Ответы [ 2 ]

1 голос
/ 26 июня 2014

Мои первые мысли - проверить ограничивающие координаты указателя;посмотрите, охватывают ли они всю вашу геометрию.Во-вторых, пространственные индексы, оставленные по умолчанию 16 ММММ, по моему опыту, работают очень плохо.Я не уверен, почему это по умолчанию.Я написал кое-что о настройке пространственного индекса на этот ответ .

Сначала убедитесь, что индекс охватывает все геометрии.Затем попробуйте уменьшить число ячеек на объект до 8. Если ни одна из этих двух вещей не дает какого-либо улучшения, возможно, стоит потратить время на запуск процедуры настройки пространственного индекса в ответе, который я привел выше.

Последняя мысль - это такое состояниеграницы имеют так много вершин и имеют много полигонов границ состояний, с которыми вы тестируете пересечение, очень хорошо может потребоваться столько времени, не сокращая их.

О, и с тех пор, как прошло два года, начиная с SQL ServerВ 2012 году появилась тесселяция GEOMETRY_AUTO_GRID , которая выполняет настройку индекса и большую часть времени выполняет большую работу.

0 голосов
/ 14 января 2013

Это может быть просто следствием того, что более простой план выполнения выполняется параллельно, тогда как другой - нет.Однако в первом плане выполнения есть предупреждение, которое, возможно, стоит изучить.

...