Nous avons une table avec une colonne XML contenant beaucoup de données, cela a bien fonctionné dans nos environnements de développement, mais lorsque la taille de la table a augmenté (près de 10 000 lignes), nous avons commencé à voir problèmes.Performances des colonnes XML SQL Server 2008 Problème
Juste faire SELECT * 12 secondes seulement ...
Toutes les suggestions pour y remédier?
Merci d'avance.
Vous pouvez vérifier plusieurs choses - au moins si le succès de la performance est surtout lorsqu'ils traitent avec et la sélection des données de la colonne XML:
vous pouvez mettre index on your XML column - cela peut aider si vous avez besoin saisir beaucoup de données à partir de la colonne XML. Un mot d'avertissement: les index XML utilisent un lot de l'espace disque - dans notre cas, une base de données de 1,5 Go a grimpé jusqu'à 11 Go de taille de disque .... à utiliser avec prudence! Vous pouvez "faire surface" certains éléments de votre XML vers la table "parent" en tant que colonnes calculées et persistantes et ainsi trouver les lignes dont vous avez besoin plus rapidement (nécessite une fonction stockée - mais c'est vraiment une bonne technique si vous avez ce besoin)
aussi: jamais une SELECT * de toute façon - et si vous n'avez pas besoin de la colonne XML - ne sélectionnez pas - il sera très bavard et d'utiliser un peu de mémoire.
Juste pour ajouter un peu à ce que marc_s a dit: Je recommanderais aussi un index - 10k enregistrements n'est pas beaucoup. Mais assurez-vous que vous ajoutez un index sur la bonne chose - habituellement les meilleurs endroits pour mettre des index sont sur les colonnes qui sont utilisées pour les conditions JOIN, les clauses WHERE ou les clauses ORDER BY. Si votre requête n'utilise pas le XML lui-même pour ces cas, vous pouvez être mieux servi en créant un index sur une colonne différente (par exemple, si vous effectuez une recherche sur un ID figurant dans une colonne non XML, vous pouvez voir plus d'avantages en créant l'index sur l'ID). Si l'extraction des données XML est lente, vous pouvez envisager de créer un index de couverture (en utilisant le mot-clé INCLUDE), où vous avez un index sur l'ID, mais INCLURE une expression qui extrait la valeur de la colonne XML. Cela a fait une énorme différence pour moi sur l'un de mes projets, mais comme toujours, assurez-vous de tester la performance.
Bien sûr, si vos requêtes sont en train de faire Adhérez/OU/ORDER BY sur les données XML, alors vous devriez probablement faire ce que recommande marc_s et créer l'index sur la colonne XML.
Merci pour les deux réponses, cela m'a donné quelques idées sur ce que nous devons améliorer dans notre application. Cependant, notre scénario n'est pas aussi compliqué pour l'instant, nous ne faisons pas beaucoup d'interrogation sur XML en SQL pour l'instant, le cas d'utilisation de ce problème est que nous tirons toute la colonne et le code d'application le convertit en un objet où le reste du application peut l'utiliser, mais juste en tirer quelques milliers à la fois prend du temps. Avec cela dit et étant donné que nous tirons toute la colonne serait l'indice encore aider? – AVP06
Est-ce que cela ferait également une différence si nous ne tirions que des nœuds XML partiels au lieu d'une colonne entière? – AVP06
En général, moins vous transférez de données de la base de données vers le client, plus vous améliorez les performances. C'est pourquoi vous devriez éviter "SELECT *" et ne sélectionner que les colonnes nécessaires. De même, si vous pouvez réduire le nombre de lignes renvoyées (en filtrant les enregistrements d'une façon ou d'une autre), cela améliorera également les performances. Si un index est utile pour votre filtrage, alors oui l'index accélérerait les choses. Et oui, il est possible que tirer un sous-ensemble du XML aiderait aussi. Difficile à dire à coup sûr sans test. – JohnD
Si vous interrogez des enregistrements et que vous filtrez des données dans un type de données XML, vous demandez à SQL Server d'examiner tout le contenu XML pour trouver des résultats.
Pour accélérer les choses, combinez des filtres de type de données XML avec des expressions de recherche en texte intégral. La recherche en texte intégral réduit les résultats (selon votre degré de précision) avant que le XML ne soit analysé et recherché. Il peut économiser beaucoup de CPU et d'E/S. Voici un exemple:
SELECT *
FROM Table
WHERE CONTAINS(XmlColumn,'value')
AND XmlColumn.exist('/element/element/text()[contains(.,"value")]') = 1
Ceci est documenté par Microsoft here, et vous pouvez examiner votre avant et après l'exécution de vos requêtes par des statistiques sur.Voici comment vous activez les statistiques:
SET STATISTICS IO ON;
SET STATISTICS TIME ON;
Avez-vous les index requis sur la table? Je soupçonne que la taille des lignes de données est juste trop grande, et prend juste beaucoup de temps pour retourner les données ... –
Comment faites-vous le 'SELECT *'? –