Não consigo fazer com que o SQL Server utilize um índice espacial básico em um GEOGRAPHY
objeto, mesmo para as consultas mais simples.
Aqui está uma reprodução do dbfiddle.uk que demonstra como criar uma tabela simples com uma GEOGRAPHY
coluna chamada Coordinates
, adicionar 1 linha com um polígono a essa tabela e, em seguida, criar um índice espacial na Coordinates
coluna.
A consulta parece que deveria ser SARGable, mas ainda recebo uma varredura de índice clusterizado, em vez de uma busca de índice não clusterizado no índice espacial:
Se eu tentar forçar a dica de índice, recebo o erro clássico:
Msg 8635, Nível 16, Estado 4, Linha 15
O processador de consulta não pôde produzir um plano de consulta para uma consulta com uma dica de índice espacial. Motivo: Índices espaciais não suportam o comparador fornecido no predicado. Tente remover as dicas de índice ou remover SET FORCEPLAN.
Portanto, não é que o SQL Server pense que a verificação do índice clusterizado seja mais eficiente, mas sim que ele não consegue sequer criar um plano de consulta para o índice espacial.
De acordo com a documentação da Microsoft sobre Índices Espaciais , a STDistance()
função deve ser aplicável em um predicado para sargabilidade de índices espaciais:
Os índices espaciais suportam as seguintes formas de predicado:
- geografia1.STDistance(geografia2) <= número
Estou sendo burro?
A documentação que você vincula diz
Portanto, enquanto você estiver procurando por casos em que o resultado da função de distância seja menor que (ou menor ou igual a) algum número, você não deverá ver uma mensagem sobre um "comparador fornecido no predicado" inválido.
(As condições também devem ser expressas como acima = por exemplo,
1 > Coordinates.STDistance(@Point)
falha ao vincular explicitamente para forçar o índice espacial nomeado com "Motivo: Não foi possível encontrar o método espacial binário necessário em uma condição")O índice espacial pode ser forçado com ou uma dica
FORCESEEK
explícita ( Fiddle ). A dica de índice explícita parece dar informações mais úteis no caso de uma falha.INDEX
Se você forçar o índice espacial no seu caso, o plano de execução chama a
[GeodeticTessellation]
função com valor de tabela passando parâmetros@Point, 768, 9, 1, @Distance
para obter os valores a serem usados no índice espacial seek768
é o padrãoSPATIAL_WINDOW_MAX_CELLS
e pode ser substituído pela dica correspondente. Não tenho certeza do que eles9,1
correspondem.Isso emite 8 linhas que são então usadas para buscar no índice espacial, um agregado colapsa o resultado dessa junção para produzir uma linha por PK que é então usada em uma pesquisa de índice clusterizado contra a tabela base e, finalmente, há um filtro com um predicado residual. A regra do otimizador responsável por isso é
SpatialIntersectFilterOverGridIndex
.No caso dos seus dados de exemplo, isso custa 45 vezes mais do que apenas escanear a tabela e avaliar o predicado em relação a cada linha (custos de subárvore de
0.0042838
vs0.193235
)Seu fiddle original tinha uma expressão
WHERE Coordinates.STDistance(@Point) IS NOT NULL
. Este não é um dos dois predicados comparadores suportados paraSTDistance
que podem usar um índice espacial (exceto se a consulta também atender a todas as condições para uma ordenação de "vizinho mais próximo" ).STDistance()
método deve usar essa coluna nas cláusulasWHERE
andORDER BY
.PERCENT
declaração.STDistance()
método.WHERE
cláusula, então o predicado que contémSTDistance()
o método deve ser conectado por uma conjunção AND aos outros predicados. OSTDistance()
método não pode estar em uma parte opcional da cláusula WHERE.STDistance()
método.STDistance()
expressão naORDER BY
cláusula deve serASC
.STDistance
os retornosNULL
devem ser filtrados.Isso essencialmente acaba adicionando um predicado implícito.
O plano de execução para
Funciona de forma semelhante a este pseudocódigo
onde ele tenta aumentar exponencialmente as distâncias em ordem e pode parar na iteração encontrando pelo menos
@N
resultados e retornar osTOP @N
resultados para aquele nível (ou os resultados para o nível final se nenhuma das distâncias tentadas encontrou@N
resultados)