0

Je travaille sur la procédure stockée. Qui utilise view et convertit la table resultset au format XML. Nous avons utilisé l'instruction 'POUR XML AUTO, ROOT (' toxicsite '), TYPE'. La vue me renvoie les enregistrements 14k et après sa conversion en XML ... Cela prend 2 min. Besoin d'aide pour une autre alternative ou comment je peux Optimiser la requête TransformerL'utilisation de FOR XML AUTO, ROOT ('RootName'), TYPE pour les enregistrements 14K rend SQL Query lente

+0

juste pour obtenir cela correctement: La requête en cours d'exécution sans 'pOUR xml' est assez rapide, mais quand vous ajoutez' pOUR xml' il ralentit fait? Comment mesurez-vous le temps? Que faites-vous avec le XML? 14k records c'est pas mal. XML n'est pas conçu pour des données plus volumineuses ... – Shnugo

+0

Oui ... Si j'obtiens des données à partir de la vue, ça revient en 17 secondes (14k Records) .Mais si j'applique ForXML ... C'est une exigence .. J'envoie ce XML à l'API pour un traitement ultérieur. –

Répondre

0

Je viens d'essayer cela avec un simple SELECT TOP 14000 * FROM SomeBigTable. SSMS est prêt après 2 secondes. Avec FOR XML AUTO il revient tout aussi vite. Je ne pense pas, que la création du XML prend autant de temps ...

Si votre VIEW est très complexe, il se peut que AUTO vous fasse du tort. AUTO essaie de trouver une structure interne appropriée pour votre requête (imbrications des données relatives)

En tir rapide vous pouvez essayer FOR XML RAW,TYPE juste pour vérifier la différence de performance. Le mieux était une approche explicite avec FOR XML PATH, où vous pouvez spécifier les imbrications et les relations vous-même.

S'il y a des BLOBs impliqués (VARBINARY données), vous avez les coûts supplémentaires de conversion de ces base64, s'il y a beaucoup de chaînes en jeu, surtout si elles ont beaucoup de non latins caractères, vous avez le supplément les coûts de codage d'entité ...

En général XML est étonnamment rapide ...