Cela dépend.
Cela dépend totalement de ce que vous visualisez à travers la vue. Mais très probablement en réduisant votre effort et en offrant de meilleures performances. Lorsque l'instruction SQL fait référence à une vue non indexée, l'analyseur et l'optimiseur de requête analysent la source de l'instruction SQL et de la vue, puis les résolvent en un seul plan d'exécution. Il n'y a pas un plan pour l'instruction SQL et un plan distinct pour la vue.
Une vue n'est pas compilée . C'est une table virtuelle composée d'autres tables. Lorsque vous le créez, il ne réside pas quelque part sur votre serveur. Les requêtes sous-jacentes qui composent la vue sont soumises aux mêmes gains de performances ou dings de l'optimiseur de requêtes. Je n'ai jamais testé les performances sur une vue par rapport à sa requête sous-jacente, mais j'imagine que les performances peuvent varier légèrement. Vous pouvez obtenir de meilleures performances sur une vue indexée si les données sont relativement statiques. C'est peut-être ce que vous pensez peut-être en termes de "compilé".
Avantages des vues :
- Afficher les données sans les stocker dans l'objet.
- Restreindre l'affichage d'un tableau, c'est-à-dire masquer certaines colonnes dans les tableaux.
- Joignez deux tables ou plus et affichez-les comme un seul objet pour l'utilisateur.
- Restreindre l'accès à une table afin que personne ne puisse insérer les lignes dans la table.
Consultez ces liens utiles :
- Performance de VIEW par rapport à l'instruction SQL
- Une vue est-elle plus rapide qu'une requête simple ?
- Mysql VIEWS vs requête PHP
- Les vues MySql sont-elles dynamiques et efficaces ?
- Vue matérialisée par rapport aux tables :Quels sont les avantages ?
- interroge sur une vue plus lente que l'exécution directe de SQL ?
- Une solution de contournement pour les problèmes de performances des vues TEMPTABLE
Observez les gains de performances en utilisant des vues indexées dans SQL Server
