просторовий показник просторового індексу сервера


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) 

Хтось знає, що тут відбувається?


Я просто переживав щось подібне dba.stackexchange.com/questions/61289/… днями ... Я не генерував багатокутник з тексту, але перетинав точки та багатокутники ... Я вказав використовувати просторовий індекс на точку, яка мала великі швидкісні результати. Потім я спробував використати просторовий індекс на полігоні і мав дуже низьку продуктивність ... що здається точно протилежною вашій проблемі!
DPSSpatial

4
Якщо ви задумаєтесь, зміна розміру конвертів пошуку повинна мати суттєвий вплив на запит - чим більше рядків, які повертаються через індекс, тим повільніше відповідь. У якийсь момент стає швидше повне сканування таблиці та викидання рядків на основі конверта. Я б запропонував вам більше часу проводити з просторовими параметрами індексу, оскільки, ймовірно, є місце для оптимізації індексу.
Вінс

Чи ваші записи представляють бали? Про це не було сказано. Також ви можете опублікувати синтаксис створення індексу, який ви використовували? Це було AutoGrid?
gischimp

Я використав "Географія автоматичного пояса" та "Клітини на об'єкт" = 4000. Пересікав 110+ мільйонів пунктів з полігонами ~ 45K.
Майкл

1
Ще одна річ, яку ви повинні пам’ятати, - це те, що перетин є складною операцією, спочатку воно повинно виглядати, чи пов'язані елементи перетинаються, відносно швидке функціонування через індекси, але потім для кожного елемента, який відповідає, він повинен обчислити, чи перетинається кожен окремий елемент, який це ще одна, більш дорога операція, яка стає ще дорожчою, оскільки полігони складніші та / або більш численні.
AKK2

Відповіді:


1

Як коментує @Vince :

Якщо ви задумаєтесь, зміна розміру конвертів пошуку повинна мати суттєвий вплив на запит - чим більше рядків, які повертаються через індекс, тим повільніше відповідь. У якийсь момент стає швидше повне сканування таблиці та викидання рядків на основі конверта. Я б запропонував вам більше часу проводити з просторовими параметрами індексу, оскільки, ймовірно, є місце для оптимізації індексу.

Використовуючи наш веб-сайт, ви визнаєте, що прочитали та зрозуміли наші Політику щодо файлів cookie та Політику конфіденційності.
Licensed under cc by-sa 3.0 with attribution required.