Vue SQL Server 2005 vs vue matérialisée vs procédure stockée

Question

Si j'ai une table contenant des dizaines de milliers d'enregistrements de comptes pour plusieurs emplacements.

Existe-t-il une différence de vitesse si j'interroge une vue qui sélectionne tous les comptes pour un emplacement spécifique et une procédure stockée avec la même instruction SQL?

EDIT: Je suis tombé sur cette vue matérialisée. Il semble que cela serait toujours utilisé.

Quand voudriez-vous utiliser une procédure de stockage, une vue et une vue matérialisée? Quels avantages et inconvénients souhaitez-vous garder à l’esprit lors de la prise de décision?

Answer 1

Réponse courte: "Cela dépend"

Réponse plus longue: "Cela dépend de la forme de la requête"

Comme pour toute question sur les performances dans SQL Server (quoi de mieux que x / y), il n'y a pas de réponse correcte. Dans le cas de vues par rapport à des sprocs, il n’existe aucun moyen de prédire de manière fiable lequel sera le plus rapide (le cas échéant), à moins de profiler la requête.

J'ai vu les deux être plus rapides, et cela dépend de la façon dont la vue a été utilisée et de la question de savoir si cela fait partie d'une requête plus importante. J'ai également constaté que les vues ralentissaient les requêtes, car elles peuvent masquer beaucoup de complexité dont la requête utilisant la vue n'a pas réellement besoin.

Vous devez évaluer vos objectifs: si vous ne voulez que pouvoir accéder aux lignes du tableau et que vous ne souhaiterez pas utiliser le résultat dans le cadre d'une autre requête, choisissez une procédure stockée, en particulier si la requête sur la table doit prendre une clause WHERE.

D'où la requête va-t-elle être appelée? Une autre partie de SQL? Un cadre d'application? Une couche d'accès aux données personnalisée? Cela vaut la peine de réfléchir à la manière dont le code d'appel va assembler la requête, car cela peut affecter la manière dont SQL Server finit par mettre en cache et réutiliser le plan d'exécution. Si vous ne faites que combiner un ensemble de SQL dynamique, les performances risquent de souffrir légèrement, car SQL Server peut avoir besoin de reconstruire le plan de requête à chaque fois; Ainsi, dans ce cas, un sproc a l'avantage d'un plan mis en cache. Si la couche d'accès est intelligente et utilise du SQL dynamique paramétré, il n'y en a peut-être pas tellement.

Conclusion: comprenez ce que vous voulez réaliser. Puis profilez, réglez, peaufinez et répétez jusqu'à ce que vous soyez satisfait.

Answer 2

Une vue et une procédure stockée sont toutes deux compilées dans la base de données. Elles sont donc plus rapides qu'une requête directe. La différence de vitesse entre elles apparaît lorsque vous devez avoir des paramètres dynamiques. Les vues ne les acceptent pas.

Chacun a sa propre utilisation. Les vues peuvent être utilisées dans d'autres requêtes ou vues, les procédures stockées ne peuvent être exécutées. Mais à votre question avec le même SELECT * FROM ils ont exactement la même vitesse.

Answer 3

Oui et non.

Une vue est une définition de requête qui est fondamentalement remplacée sur place lors de son utilisation et elle est compilée dans la requête qui référence la vue. Cela signifie que l'exécution dépend de la requête qui fait référence à la vue . Si la requête est un simple SELECT * FROM view , il s'agira pratiquement du même plan d'exécution que la procédure équivalente. Toutefois, si la requête est SELECT onefield FROM view , la requête est significativement différente. Il n’existe pas de procédure équivalente et cette requête peut donner de bien meilleurs résultats en raison de la réduction de la liste de projections.

Il existe également d’énormes différences de convivialité. Une procédure stockée ne peut être exécutée. Une vue peut être sélectionnée parmi et utilisées avec plusieurs autres instructions telles que des jointures, des sous-requêtes et autres.

Etant donné la plus grande flexibilité des vues, à moins qu'aucun autre facteur ne joue un rôle, une procédure n'a de sens que si vous avez des paramètres, car les vues ne peuvent en avoir.

Answer 4

Les réponses à cette Publier fournira des informations utiles sur les vues indexées (matérialisées) de SQL Server.

Answer 5

J'ai également vu que chacun était plus rapide que l'autre, selon le contexte.

La règle générale que je suis est la suivante: si la vue est complexe WHERE, dépend d’autres vues moyennement complexes ou est le résultat d’un UNION [ALL], il est presque certain que SQL S. ne pourra pas fonctionner correctement. propagez WHERE les conditions s’appliquant à la vue jusqu’aux tables individuelles. Vous obtiendrez donc des scans de table (sauf s’il s’agit d’une vue matérialisée), sinon vos plans d’exécution seront beaucoup plus complexes (et lents) que ce qu’ils ont pourrait être.

Dans ces cas, il vaut mieux opter pour un proc. Et comme d’autres l’ont dit, profilez toujours!