SQL Server Indexé Voir la question

Question

J'ai besoin de créer un rapport qui tue le processeur et prend beaucoup de temps à s'exécuter.

Je pense que je pourrais accélérer cela de manière significative en créant une vue d'index qui conserve toutes ces données en un seul endroit, ce qui facilite grandement la requête/le rapport. Ce point de vue ne serait pas seulement utilisé pour le rapport, car je pense que cela profiterait à quelques domaines de la couche de données.

La vue indexée contiendra potentiellement plus de 5 millions d'enregistrements, je ne trouve pas d'indications sur le moment où les vues indexées ne sont plus recommandées. Je suppose qu'une vue d'index de cette taille prendrait beaucoup de temps à construire au démarrage de SQL, mais j'espère qu'après cela le coût de maintenance sera minime.

Existe-t-il une sorte de guide de bonnes pratiques pour savoir quand utiliser les vues d'index et quand ne pas les utiliser? Est-ce que la vue se reconstruirait après chaque redémarrage du serveur ou serait-elle stockée quelque part sur le disque?

Answer 1

L'index associé à votre vue indexée sera mis à jour chaque fois que des mises à jour seront apportées à l'une des colonnes de l'index.

Un nombre élevé de mises à jour va probablement tuer les avantages. Si c'est principalement des lectures alors ça fonctionnera bien. Les avantages réels des vues indexées sont lorsque vous avez des agrégats qui sont trop chers pour être calculés en temps réel.

S'il vous plaît voir: Improving Performance with SQL Server 2008 Indexed Views:

vues indexées peuvent augmenter les performances des requêtes de la manière suivante:

• agrégations peuvent être précalculées et stockées dans l'index pour minimiser calculs coûteux lors de la requête exécution.
• Les tables peuvent être pré-assemblées et l'ensemble de données résultant peut être stocké.
• Des combinaisons de jointures ou d'agrégations peuvent être stockées.

L'optimiseur de requêtes indexées vues considère que pour les requêtes avec coût non négligeable. Ceci évite les situations où essayant de faire correspondre différentes vues indexées pendant l'optimisation de la requête coûte plus que les économies réalisées par l'utilisation de la vue indexée . Les vues indexées sont rarement utilisées dans les requêtes dont le coût est inférieur à 1.

Les applications qui bénéficient de la mise en œuvre des vues indexées comprennent:

• charges de travail aide à la décision.
• Marquages ​​de données.
• Entrepôts de données.
• Magasins et sources de traitement analytique en ligne (OLAP).
• Charges de travail d'exploration de données.

à partir du type de requête et un point de vue motif , les applications bénéficiant peuvent être caractérisés comme ceux contenant :

• jointures et agrégations de grandes tables.
• Modèles répétés de requêtes.
• Agrégations répétées sur des ensembles de colonnes identiques ou se chevauchant.
• Jointures répétées des mêmes tables sur les mêmes clés.
• Combinaisons de ce qui précède.

Answer 2

Je ne connais pas de conseils concernant la taille des vues indexées. Il s'agit en fait d'une table distincte qui est mise à jour "automagiquement" chaque fois que les tables de base dont elle dépend sont mises à jour, donc j'ai tendance à la considérer comme une table séparée. En ce qui concerne votre question sur la construction de l'index - il est stocké sur le disque, comme tous les autres index, de sorte qu'il ne soit pas reconstruit lors du redémarrage du serveur (autre que toute réparation due à des transactions n'ayant pas terminé avant le redémarrage).

Answer 3

Une vue indexée (vue matérialisée alias) est maintenue par SQL Server après chaque modification de la table sous-jacente (s). Inutile de dire que vous ne devriez pas avoir une vue indexée sur une table qui a du trafic.

Pour votre problème, une meilleure solution serait d'exécuter la requête et le stocker dans sa propre table, comme:

select * into CachedReport from YourView 

Cela vous donnera la performance d'une vue indexée, alors que vous pouvez décider quand pour le rafraîchir. Par exemple, vous pouvez l'actualiser en exécutant la requête select into à partir d'un travail planifié tous les soirs.

Answer 4

Il n'y a pas de limite stricte de nombre de lignes quand utiliser une table ou une vue matérialisée. Cependant, en tant que ligne guide, évitez une vue matérialisée sur les tables volatiles - la charge peut tuer votre serveur.

Tout d'abord comme Timothy suggéré vérifier les index sur vos tables sous-jacentes, puis les statistiques. Votre Optimiseur de requête peut être juste sur la piste complète en raison de statistiques manquantes/obsolètes. Si cela n'aide pas avec les performances, vérifiez quelles sont les données réellement requises de la vue, car je pense que a) le nombre de lignes et b) la taille de ligne est ce qui tue votre serveur en chargeant toute la vue dans la table temporaire et en l'exécutant par la contention d'E/S.