Estou cruzando um ponto com um conjunto de polígonos. A consulta é indexada e os polígonos não se sobrepõem, mas o plano de consulta parece pensar que, em vez de 1 linha, retornarei 18 mil linhas, e isso resulta em um plano de consulta ruim.
Em particular, os nós mais à direita do plano de consulta parecem pensar que a função STPointFromText retornará uma cardinalidade de 1000 e que a interseção desse conjunto de pontos com o índice geométrico retorna 30% das 54k linhas. (executou 1 milhão de pontos na tabela sem encontrar um contra-exemplo que realmente retornasse mais de 1 linha)
O resultado não é horrível nesta consulta abreviada, mas quando eu uno a saída disso em qualquer outra coisa, a estimativa de alta cardinalidade força a tabela upstream a ser um tablescan+hashmap, mesmo que a consulta geral retorne 1 linha. Essa consulta estendida está sendo executada algumas vezes por segundo, então estou me perguntando como posso otimizar isso.
O índice espacial é HHHH, para uma resolução mais alta (aproximadamente 4.000km do lado mais longo do domínio) de aproximadamente 80x50m, existem 56k polígonos no índice, com tamanho mínimo esperado de ~100m.
Observe a diferença entre as linhas est e as reais.
Plano de consulta estimado.
Parece que você deseja obter rowgoals para desempenhar sua parte na consulta - então tente usar
TOP(1), talvez com testes para evitar NULLs (no caso de SRIDs não correspondentes). Dessa forma, você pode obter a funcionalidade "vizinho mais próximo" para entrar em ação. Sei que você está usando o Contains, mas deseja usar um método que informe ao QO que você obterá apenas uma única linha de volta.http://blogs.lobsterpot.com.au/2014/08/14/sql-spatial-getting-nearest-calculations-working-properly/ pode ter algumas dicas...