desempenho do índice espacial do servidor sql


14

Eu tenho uma tabela com cerca de 2 milhões de registros. Eu crio um índice espacial, usando os padrões diferentes da caixa delimitadora. Tenho notado que algumas consultas são extremamente rápidas e outras extremamente lentas. O fator determinante aparece no tamanho do polígono usado na consulta.

Em áreas de pesquisa maiores, o uso WITH(INDEX(SIX_FT5))diminui consideravelmente a consulta (de 0 segundos a mais de 15 segundos). Em áreas de pesquisa menores, exatamente o oposto é verdade.

Aqui estão algumas das consultas que estou testando:

Rápido:

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) 

Lento:

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) 

Alguém sabe o que está acontecendo aqui?


Eu estava passando por algo parecido com dba.stackexchange.com/questions/61289/… outro dia ... eu não estava gerando um polígono a partir de texto, mas estava cruzando pontos e polígonos ... especifiquei para usar o índice espacial no ponto, que teve ótimos resultados de velocidade. Então tentei usar o índice espacial no polígono e tive um desempenho muito ruim ... o que parece exatamente o oposto do seu problema!
precisa saber é o seguinte

4
Se você pensar bem, alterar o tamanho do envelope de pesquisa deve ter um impacto significativo na consulta - quanto mais linhas forem retornadas por um índice, mais lenta será a resposta. Em algum momento, fica mais rápido fazer a varredura completa da tabela e jogar fora as linhas com base no envelope. Sugiro que você gaste mais tempo com as opções de índice espacial, pois provavelmente você tem espaço para otimização do índice.
Vince

Seus registros estão representando pontos? Isso não foi afirmado. Além disso, você pode publicar a sintaxe de criação de índice usada? Foi o AutoGrid?
Gischimp #

Eu usei 'Geography Auto Gird' e 'Cells per Object' = 4000. Interseção de mais de 110 milhões de pontos com ~ 45K polígonos.
Michael Michael

1
Outra coisa que você deve lembrar é que uma interseção é uma operação complexa; primeiro, ele deve procurar se os elementos vinculados se cruzam, operação relativamente rápida por meio de índices, mas, em seguida, para cada item correspondente, deve calcular se cada item realmente se cruza, o que é mais uma operação mais cara, que se torna ainda mais cara à medida que os polígonos são mais complexos e / ou mais numerosos.
AKK2

Respostas:


1

Como comentado por @Vince :

Se você pensar bem, alterar o tamanho do envelope de pesquisa deve ter um impacto significativo na consulta - quanto mais linhas forem retornadas por um índice, mais lenta será a resposta. Em algum momento, fica mais rápido fazer a varredura completa da tabela e jogar fora as linhas com base no envelope. Sugiro que você gaste mais tempo com as opções de índice espacial, pois provavelmente você tem espaço para otimização do índice.

Ao utilizar nosso site, você reconhece que leu e compreendeu nossa Política de Cookies e nossa Política de Privacidade.
Licensed under cc by-sa 3.0 with attribution required.