производительность пространственного индекса sql сервера

14

У меня есть таблица с около 2 миллионов записей. Я создаю пространственный индекс, используя значения по умолчанию, отличные от ограничительной рамки. Я заметил, что некоторые запросы очень быстрые, а некоторые очень медленные. Определяющим фактором является размер многоугольника, используемого в запросе.

В больших областях поиска использование значительно WITH(INDEX(SIX_FT5))замедляет запрос (от 0 секунд до 15+ секунд). На небольших поисковых площадях, прямо противоположное это правда.

Вот некоторые из запросов, с которыми я тестирую:

Быстро:

SELECT TOP(1000) * FROM [FT5] WHERE (shape.STIntersects(geometry::STGeomFromText('POLYGON ((-133462.805381701 -668610.241000959, 2934415.68824241 -668610.241000959, 2934415.68824241 2200521.65831815, -133462.805381701 2200521.65831815, -133462.805381701 -668610.241000959))', 2264)) = 1)

Медленный:

SELECT TOP(1000) * FROM [FT5] WITH(INDEX(SIX_FT5)) WHERE (shape.STIntersects(geometry::STGeomFromText('POLYGON ((-133462.805381701 -668610.241000959, 2934415.68824241 -668610.241000959, 2934415.68824241 2200521.65831815, -133462.805381701 2200521.65831815, -133462.805381701 -668610.241000959))', 2264)) = 1)

Кто-нибудь знает, что здесь происходит?

sql-server performance spatial-index mdm20
источник
Я только что проходил нечто подобное dba.stackexchange.com/questions/61289/… на днях ... Я не генерировал многоугольник из текста, но пересекал точки и многоугольники ... Я указал использовать пространственный индекс на момент, который имел отличные результаты скорости. Затем я попытался использовать пространственный индекс на многоугольнике, и у него была очень низкая производительность ... что кажется полной противоположностью вашей проблеме!
DPSSpatial
4
Если подумать, то изменение размера поискового конверта должно оказать значительное влияние на запрос - чем больше строк возвращается через индекс, тем медленнее ответ. В какой-то момент он быстрее выполняет полное сканирование таблицы и выбрасывает строки на основе конверта. Я бы посоветовал вам больше времени уделять опциям пространственного индекса, поскольку у вас, вероятно, есть место для оптимизации индекса.
Винс
Ваши записи представляют точки? Это не было заявлено. Кроме того, вы можете опубликовать синтаксис создания индекса, который вы использовали? Был ли это AutoGrid?
Гишимп
Я использовал 'Geography Auto Gird' и 'Cells per Object' = 4000. Пересекли 110+ миллионов точек с ~ 45K полигонов.
Майкл
1
Еще одна вещь, которую вы должны помнить, это то, что пересечение - это сложная операция, сначала она должна посмотреть, пересекаются ли связанные элементы, относительно быстрая операция по индексам, но затем для каждого соответствующего элемента она должна рассчитать, действительно ли пересекается каждый отдельный элемент, что это еще одна, более дорогая операция, которая становится еще более дорогой, поскольку полигоны являются более сложными и / или более многочисленными.
AKK2

Ответы:

1

Как прокомментировал @Vince :

Если подумать, то изменение размера поискового конверта должно оказать значительное влияние на запрос - чем больше строк возвращается через индекс, тем медленнее ответ. В какой-то момент он быстрее выполняет полное сканирование таблицы и выбрасывает строки на основе конверта. Я бы посоветовал вам больше времени уделять опциям пространственного индекса, поскольку у вас, вероятно, есть место для оптимизации индекса.

PolyGeo
источник