performances de l'index spatial du serveur SQL

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
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

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

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

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
source