Une vue est-elle plus rapide qu'une simple requête?
est un
select * from myView
plus rapide que la requête elle-même pour créer la vue (afin d'avoir le même ensemble de résultats):
select * from ([query to create same resultSet as myView])
?
ce n'est pas totalement clair pour moi si la vue utilise une sorte de cache la rendant plus rapide par rapport à une simple requête.
14 réponses
Oui , les vues peuvent avoir un index groupé assigné et, quand ils le font, ils stockent des résultats temporaires qui peuvent accélérer les requêtes résultantes.
mise à Jour: Au moins trois personnes ont voté moi en bas sur celui-ci. Avec tout le respect que je vous dois, je pense qu'ils sont tout simplement faux; la propre documentation de Microsoft rend très clair que les vues peuvent améliorer les performances.
D'abord, les vues simples sont élargies en place et donc ne pas contribuer directement à l'amélioration du rendement - c'est vrai. Toutefois, vues indexées peut spectaculaire améliorer les performances.
Permettez-moi d'aller directement à la documentation:
après la création d'un index groupé unique sur la vue, le jeu de résultats de la vue est matérialisé immédiatement et a persisté dans le stockage physique dans la base de données, économisant le coût de réalisation de ce cher, au moment de l'exécution.
Deuxièmement, ces vues indexées peuvent fonctionner même si elles ne sont pas directement référencées par une autre requête car l'optimiseur les utilisera à la place d'une référence de table lorsque cela est approprié.
encore une fois, la documentation:
la vue indexée peut être utilisée dans l'exécution d'une requête de deux façons. La requête peut faire référence directement à la vue indexée, ou, plus important encore, l'optimiseur de requêtes peut sélectionner la vue si elle détermine que la vue peut être substituée à une partie ou à la totalité de la requête dans le plan de requête le moins coûteux. Dans le second cas, la vue indexée est utilisée à la place des tableaux sous-jacents et de leurs index ordinaires. La vue n'a pas besoin d'être référencé dans la requête pour que l'optimiseur de requête à utiliser lors de l'exécution de la requête. Cela permet aux applications existantes de bénéficier des vues indexées nouvellement créées sans changer celles application.
cette documentation, ainsi que des graphiques démontrant des améliorations de performance, peut être trouvée ici .
mise à jour 2: la réponse a été critiquée au motif que c'est l '" indice "qui procure l'avantage de rendement, et non la "vue"."Cependant, cela est facilement réfuté.
disons que nous sommes une compagnie de logiciel dans un petit pays; je vais prenez la Lituanie comme exemple. Nous vendons des logiciels dans le monde entier et conservons nos enregistrements dans une base de données SQL Server. Nous avons beaucoup de succès et donc, dans quelques années, nous avons plus d'un million de disques. Cependant, nous devons souvent déclarer les ventes à des fins fiscales et nous constatons que nous n'avons vendu que 100 copies de nos logiciels dans notre pays d'origine. En créant une vue indexée des seuls enregistrements lituaniens, nous obtenons de conserver les enregistrements dont nous avons besoin dans un cache indexé tel que décrit dans la documentation MS. Quand nous produisons nos rapports pour Ventes en Lituanie en 2008, notre recherche se fera à travers un index d'une profondeur de seulement 7 (Log2(100) avec quelques feuilles inutilisées). Si nous devions faire la même chose sans la vue et en nous basant simplement sur un index dans la table, nous aurions à parcourir un arbre d'index avec une profondeur de recherche de 21!
de toute évidence, la vue elle-même nous procurerait un avantage de performance (3x) par rapport à la simple utilisation de l'indice seul. J'ai essayé d'utiliser un exemple réel, mais vous remarquerez qu'une simple liste des ventes lituaniennes nous donneraient un avantage encore plus grand.
notez que j'utilise juste un arbre b pour mon exemple. Bien que je sois assez certain que SQL Server utilise une variante d'un arbre b, Je ne connais pas les détails. Néanmoins, le point détient.
mise à jour 3: la question Est de savoir si une vue indexée utilise seulement un index placé sur la table sous-jacente. C'est, pour paraphraser: "une vue indexée est juste la équivalent d'un index standard et il n'offre rien de nouveau ou unique à une vue."Si cela était vrai, bien sûr, alors l'analyse ci-dessus serait incorrecte! Permettez-moi de fournir une citation de la documentation de Microsoft qui démontrent pourquoi je pense que cette critique n'est pas valide ou vrai:
L'utilisation d'index pour améliorer la performance des requêtes n'est pas un concept nouveau; toutefois, les vues indexées offrent des avantages de performance supplémentaires qui ne peuvent pas être obtenus à l'aide d'index standard.
ainsi que la citation ci-dessus concernant la persistance des données dans le stockage physique et d'autres informations dans la documentation sur la façon dont les indices sont créés sur les vues, je pense qu'il est sûr de dire qu'une vue indexée est et non juste un choix SQL caché qui se trouve à utiliser un index défini sur la table principale. Donc, je continue de rester par cette réponse.
en général, n ° 151900920. Les vues sont principalement utilisées pour des raisons de commodité et de sécurité, et non pour des améliorations de la vitesse.
cela dit, SQL Server 2000 et au-dessus ont une fonctionnalité spéciale appelée vues indexées que peut améliorer considérablement les performances, mais vous devez créer des vues indexées suivant un très ensemble spécifique de lignes directrices .
il y a un référence importante dans les livres en ligne en ce qui concerne view resolution .
voici un article qui décrit le avantages et création de vues indexées :
depuis de nombreuses années, Microsoft ® SQL Server™ a soutenu la capacité de créer tables virtuelles connues sous le nom de vues. Historiquement, ces points de vue ont servi buts principaux:
pour fournir un mécanisme de sécurité qui empêche les utilisateurs d'un certain sous-ensemble de données dans un ou plusieurs tableaux de base.
pour fournir un mécanisme qui permet les développeurs de personnaliser comment les utilisateurs peuvent voir logiquement les données stockées dans la base table.
avec SQL Server 2000, le la fonctionnalité des vues du serveur SQL était élargi pour fournir le rendement du système avantage. Il est possible pour créer un indice de regroupement unique sur une vue, comme ainsi que des indices non classés, à améliorer l'accès aux données de performance sur les la plupart des requêtes complexes. Dans SQL Server 2000 et 2005, un point de vue qui l'indice de regroupement unique se réfère à comme une vue indexée.
dans SQL Server au moins, les plans de requête sont stockés dans le cache plan pour les vues et les requêtes SQL ordinaires, basées sur les paramètres de requête/vue. Pour les deux, ils sont retirés du cache quand ils ont été inutilisés pendant une période assez longue et l'espace est nécessaire pour une autre requête nouvellement soumise. Après quoi, si la même requête est émise, elle est recompilée et le plan est remis dans le cache. Donc non, il n'y a pas de différence, étant donné que vous réutilisez la même requête SQL et la même vue avec la même fréquence.
évidemment, en général, une vue, par sa nature même (que quelqu'un pensait qu'elle devait être utilisée assez souvent pour en faire une vue) est généralement plus susceptible d'être "réutilisée" que n'importe quelle déclaration SQL arbitraire.
modifier: j'avais tort, et vous devriez voir réponse de points ci-dessus.
je ne peux pas parler de l'expérience avec SQL Server , mais pour la plupart des bases de données de la réponse serait non. Le seul avantage potentiel que vous obtenez, du point de vue de la performance, en utilisant une vue est qu'elle pourrait potentiellement créer des chemins d'accès basés sur la requête. Mais la principale raison d'utiliser une vue est de simplifier une requête ou de normaliser un moyen d'accès à certaines données dans une table. En général, vous n'aurez pas d'avantage de performance. J'ai peut-être tort, bien que.
je proposerais un exemple un peu plus compliqué et chronométrez-le vous-même pour le voir.
il peut être plus rapide si vous créez une vue matérialisée ( avec liaison schématique ). Non vues matérialisées exécuter des requêtes.
D'après ce que j'ai compris, il y a quelque temps, une vue serait plus rapide car SQL Server pourrait stocker un plan d'exécution et ensuite l'utiliser au lieu d'essayer d'en trouver un à la volée. Je pense que les gains de performance de nos jours n'est probablement pas aussi grande qu'elle l'a été par le passé, mais je devrai deviner qu'il y aurait une certaine amélioration marginale pour utiliser la vue.
Je m'attends à ce que les deux requêtes fonctionnent de manière identique. Une vue n'est rien de plus qu'une définition de requête stockée, il n'y a pas de mise en cache ou de stockage de données pour une vue. L'optimiseur transformera efficacement votre première requête en deuxième lorsque vous l'exécuterez.
certainement une vue est meilleure qu'une requête emboîtée pour le serveur SQL. Sans savoir exactement pourquoi c'est mieux (jusqu'à ce que je lise le post de Mark Brittingham), j'ai fait quelques tests et j'ai expérimenté des améliorations de performance presque choquantes en utilisant une vue par rapport à une requête imbriquée. Après avoir exécuté chaque version de la requête plusieurs centaines de fois d'affilée, la version de vue de la requête terminée dans la moitié du temps. Je dirais que c'est une preuve suffisante pour moi.
il n'y a pas de pratique différente et si vous lisez BOL, vous constaterez que votre simple Vieux SQL SELECT * de X profite de la mise en cache plan, etc.
il devrait y avoir un certain gain insignifiant à avoir le plan d'exécution stocké, mais il sera négligeable.
le but d'une vue est d'utiliser la requête encore et encore. À cette fin, SQL Server, Oracle, etc. fournira typiquement une version" mise en cache "ou" compilée " de votre vue, améliorant ainsi ses performances. En général, cela devrait fonctionner mieux qu'une requête "simple", bien que si la requête est vraiment très simple, les avantages peuvent être négligeables.
maintenant, si vous faites une requête complexe, créez la vue.
dans ma conclusion, l'utilisation de la vue est un peu plus rapide qu'une requête normale. Mon procédure stockée prenait environ 25 minutes (travaillant avec un plus grand jeu de disques et de multiples jointures) et après avoir utilisé la vue (non-clustered), la performance était juste un peu plus rapide mais pas significative du tout. J'ai dû utiliser d'autres techniques/méthodes d'optimisation des requêtes pour en faire un changement radical.
tout dépend de la situation. Les vues indexées MS SQL sont plus rapides qu'une vue ou une requête normale, mais les vues indexées ne peuvent pas être utilisées dans une base de données miroir en environnement (MS SQL).
une vue dans n'importe quelle sorte de boucle causera un ralentissement sérieux parce que la vue est repeuplée chaque fois qu'elle est appelée dans la boucle. Même en tant que requête. Dans cette situation, une table temporaire utilisant # ou @ pour maintenir vos données en boucle est plus rapide qu'une vue ou une requête.
Donc, tout dépend de la situation.
sélectionner dans une vue ou dans une table n'a pas trop de sens.
bien sûr si la vue n'a pas de jointures, champs, etc. inutiles. Vous pouvez vérifier le plan d'exécution de vos requêtes, joins et Index utilisés pour améliorer les performances de la vue.
vous pouvez même créer l'index sur les vues pour des exigences de recherche plus rapides. http://technet.microsoft.com/en-us/library/cc917715.aspx
Mais si vous êtes la recherche like '%...% "que le moteur sql ne bénéficiera pas d'un index sur la colonne de texte. Si vous pouvez forcer les utilisateurs à faire des recherches...% de " que sera rapide
renvoyé à la réponse sur les forums asp : https://forums.asp.net/t/1697933.aspx?Which+est+rapide+quand+aide+SELECT+requête de+VUE+ou+Table+