wydajność indeksu przestrzennego serwera SQL

14

Mam tabelę z około 2 milionami rekordów. Tworzę indeks przestrzenny, używając wartości domyślnych innych niż obwiednia. Zauważyłem, że niektóre zapytania są bardzo szybkie, a niektóre bardzo wolne. Czynnikiem determinującym jest wielkość wielokąta użytego w zapytaniu.

W przypadku większych obszarów wyszukiwania użycie WITH(INDEX(SIX_FT5))znacznie spowalnia zapytanie (od 0 sekund do ponad 15 sekund). W mniejszych obszarach wyszukiwania jest dokładnie odwrotnie.

Oto niektóre zapytania, z którymi testuję:

Szybki:

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)

Powolny:

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)

Czy ktoś wie, co się tutaj dzieje?

sql-server performance spatial-index mdm20
źródło
Właśnie przechodziłem przez coś podobnego dba.stackexchange.com/questions/61289/ ... innego dnia ... Nie generowałem wielokąta z tekstu, ale przecinałem punkty i wielokąty ... Skorzystałem z indeksu przestrzennego w punkcie, który miał świetne wyniki prędkości. Następnie spróbowałem użyć indeksu przestrzennego na wielokącie i miałem bardzo słabą wydajność ... co wydaje się być dokładnym przeciwieństwem twojego problemu!
DPSSpatial
4
Jeśli się nad tym zastanowić, zmiana rozmiaru koperty wyszukiwania powinna mieć znaczący wpływ na zapytanie - im więcej wierszy jest zwracanych przez indeks, tym wolniejsza jest odpowiedź. W pewnym momencie szybsze staje się pełne skanowanie tabeli i wyrzucanie wierszy na podstawie obwiedni. Sugerowałbym, abyś spędzał więcej czasu z opcjami indeksu przestrzennego, ponieważ prawdopodobnie masz miejsce na optymalizację indeksu.
Vince
Czy twoje rekordy reprezentują punkty? Nie zostało to powiedziane. Czy możesz również opublikować używaną składnię tworzenia indeksu? Czy to była AutoGrid?
gischimp
Użyłem „Geography Auto Gird” i „Cells per Object” = 4000. Przecięliśmy ponad 110 milionów punktów z ~ 45K wielokątów.
Michael
1
Inną rzeczą, o której musisz pamiętać, jest to, że przecięcie jest złożoną operacją, najpierw musi sprawdzić, czy powiązane elementy przecinają się, względnie szybkie operacje przez indeksy, ale następnie dla każdego pasującego elementu musi obliczyć, czy każdy pojedynczy element przecina się, co to kolejna, bardziej kosztowna operacja, która staje się jeszcze bardziej kosztowna, ponieważ wielokąty są bardziej złożone i / lub liczniejsze.
AKK2

Odpowiedzi:

1

Jak skomentował @Vince :

Jeśli się nad tym zastanowić, zmiana rozmiaru koperty wyszukiwania powinna mieć znaczący wpływ na zapytanie - im więcej wierszy jest zwracanych przez indeks, tym wolniejsza jest odpowiedź. W pewnym momencie szybsze staje się pełne skanowanie tabeli i wyrzucanie wierszy na podstawie obwiedni. Sugerowałbym, abyś spędził więcej czasu z opcjami indeksu przestrzennego, ponieważ prawdopodobnie masz miejsce na optymalizację indeksu.

PolyGeo
źródło