performances de l'index spatial du serveur SQL

14

J'ai une table contenant environ 2 millions d'enregistrements. Je crée un index spatial, en utilisant les valeurs par défaut autres que la boîte englobante. J'ai remarqué que certaines requêtes sont extrêmement rapides et d'autres extrêmement lentes. Le facteur déterminant apparaît à la taille du polygone utilisé dans la requête.

Sur les zones de recherche plus grandes, l'utilisation WITH(INDEX(SIX_FT5))ralentit considérablement la requête (de 0 seconde à 15+ secondes). Sur les petites zones de recherche, l'exact opposé est vrai.

Voici quelques-unes des requêtes avec lesquelles je teste:

Vite:

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)

Lent:

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)

Quelqu'un sait ce qui se passe ici?

sql-server performance spatial-index mdm20
la source
Je passais juste par quelque chose de similaire dba.stackexchange.com/questions/61289/… l'autre jour ... Je ne générais pas de polygone à partir du texte, mais je croisais des points et des polygones ... J'ai spécifié d'utiliser l'index spatial sur le point, qui a eu de grands résultats de vitesse. J'ai ensuite essayé d'utiliser l'index spatial sur le polygone, et j'ai eu de très mauvaises performances ... ce qui semble être l'exact opposé de votre problème!
DPSSpatial
4
Si vous y réfléchissez, la modification de la taille de l'enveloppe de recherche devrait avoir un impact significatif sur la requête - plus il y a de lignes renvoyées via un index, plus la réponse est lente. À un certain point, il devient plus rapide de parcourir le tableau complet et de jeter les lignes en fonction de l'enveloppe. Je suggère que vous passiez plus de temps avec les options d'index spatial, car vous avez probablement de la place pour l'optimisation de l'index.
Vince
Vos dossiers représentent-ils des points? Cela n'a pas été déclaré. Pouvez-vous également publier la syntaxe de création d'index que vous avez utilisée? Était-ce AutoGrid?
gischimp
J'ai utilisé «Geography Auto Gird» et «Cells per Object» = 4000. Intersectionné plus de 110 millions de points avec environ 45 000 polygones.
Michael
1
Une autre chose que vous devez vous rappeler est qu'une intersection est une opération complexe, d'abord elle doit regarder si les éléments liés se croisent, opération relativement rapide à travers les index, mais ensuite pour chaque élément qui correspond, elle doit calculer si chaque élément se recoupe réellement, ce qui est encore une autre opération, plus coûteuse, qui devient d'autant plus coûteuse que les polygones sont plus complexes et / ou plus nombreux.
AKK2

Réponses:

1

Comme l'a commenté @Vince :

Si vous y réfléchissez, la modification de la taille de l'enveloppe de recherche devrait avoir un impact significatif sur la requête - plus il y a de lignes renvoyées via un index, plus la réponse est lente. À un certain point, il devient plus rapide de parcourir le tableau et de jeter les lignes en fonction de l'enveloppe. Je suggérerais que vous passiez plus de temps avec les options d'index spatial, car vous avez probablement de la place pour l'optimisation de l'index.

PolyGeo
la source