Une vue est-elle plus rapide qu'une simple requête ?

Question

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 resultSet) :

select * from ([query to create same resultSet as myView])

?

Je ne sais pas très bien si la vue utilise une sorte de mise en cache qui la rend plus rapide qu'une simple requête.

Answer 1

Oui , vues puede ont un index clusterisé assigné et, lorsqu'ils le font, ils stockent des résultats temporaires qui peuvent accélérer les requêtes résultantes.

La propre documentation de Microsoft indique très clairement que Views peut améliorer les performances.

D'abord, la plupart des vues que les gens créent sont simple et n'utilisent pas cette fonctionnalité, et ne sont donc pas différentes de l'interrogation directe des tables de base. Les vues simples sont développées en place et donc ne contribuent pas directement à l'amélioration des performances - c'est vrai. Cependant, les vues indexées peuvent dramatiquement améliorer les performances.

Permettez-moi de passer directement à la documentation :

Après la création d'un index cluster unique sur la vue, l'ensemble des résultats de la vue est immédiatement matérialisé et persistant dans le stockage physique de la base de données, ce qui évite d'avoir à effectuer cette opération coûteuse au moment de l'exécution.

Deuxièmement, ces vues indexées peuvent fonctionner même s'ils ne sont pas directement référencés par une autre requête car l'optimiseur les utilisera à la place d'une référence de table, le cas échéant.

Encore une fois, la documentation :

La vue indexée peut être utilisée dans l'exécution d'une requête de deux manières. La requête peut faire référence à la vue indexée directement, ou, plus important encore, l'optimiseur de requêtes peut sélectionner la vue s'il détermine que la vue peut être substituée à tout ou partie de la requête dans le plan de requête le plus économique. Dans le second cas, la vue indexée est utilisée à la place des tables sous-jacentes et de leurs index ordinaires. Il n'est pas nécessaire que la vue soit référencée dans la requête pour que l'optimiseur de requêtes l'utilise pendant l'exécution de la requête. Cela permet aux applications existantes de bénéficier des vues indexées nouvellement créées sans avoir à modifier ces applications.

Cette documentation, ainsi que des graphiques démontrant l'amélioration des performances, se trouvent à l'adresse suivante aquí .

Mise à jour 2 : la réponse a été critiquée au motif que c'est l'"indice" qui procure l'avantage en termes de performance, et non la "vue". Cependant, cette affirmation est facilement réfutable.

Disons que nous sommes une société de logiciels dans un petit pays ; je prendrai la Lituanie comme exemple. Nous vendons des logiciels dans le monde entier et conservons nos données dans une base de données SQL Server. Nous avons beaucoup de succès et, en quelques années, nous avons plus d'un million d'enregistrements. Cependant, nous devons souvent déclarer les ventes à des fins fiscales et nous découvrons que nous n'avons vendu que 100 exemplaires de notre logiciel dans notre pays d'origine. En créant une vue indexée des seuls enregistrements lituaniens, nous pouvons conserver les enregistrements dont nous avons besoin dans un cache indexé, comme décrit dans la documentation MS. Lorsque nous exécutons nos rapports sur les ventes en Lituanie en 2008, notre recherche s'effectue dans un index d'une profondeur de seulement 7 (Log2(100) avec quelques feuilles inutilisées). Si nous devions faire la même chose sans le VIEW et en nous basant uniquement sur un index dans la table, nous devrions parcourir un arbre d'index avec une profondeur de recherche de 21 !

Il est clair que 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 concret, mais vous remarquerez qu'une simple liste de ventes lituaniennes nous donnerait un avantage encore plus grand.

Notez que je n'utilise qu'un b-tree droit pour mon exemple. Je suis pratiquement certain que SQL Server utilise une variante du b-tree, mais je n'en connais pas les détails. Néanmoins, l'idée est la même.

Mise à jour 3 : La question s'est posée de savoir si une vue indexée utilise simplement un index placé sur la table sous-jacente. C'est-à-dire, pour paraphraser : "une vue indexée est juste l'équivalent d'un index standard et elle n'offre rien de nouveau ou d'unique à une vue". Si cela était vrai, bien sûr, alors l'analyse ci-dessus serait incorrecte ! Permettez-moi de vous fournir une citation de la documentation Microsoft qui démontre pourquoi je pense que cette critique n'est pas valide ou vraie :

L'utilisation d'index pour améliorer les performances des requêtes n'est pas un concept nouveau. Toutefois, les vues indexées offrent des avantages supplémentaires en termes de performances qui ne peuvent être obtenus à l'aide d'index standard.

Avec 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 index sont créés sur les vues, je pense qu'il est sûr de dire qu'une vue indexée est no juste une sélection SQL en cache qui utilise un index défini sur la table principale. Je maintiens donc ma réponse.

Answer 2

En général, non. Les vues sont principalement utilisées pour des raisons de commodité et de sécurité, et ne produisent (par elles-mêmes) aucun avantage en termes de vitesse.

Cela dit, le serveur SQL 2000 et les versions supérieures disposent d'une fonction appelée Vues indexées que puede améliorent grandement les performances, avec quelques mises en garde :

1. Toutes les vues ne peuvent pas être transformées en vues indexées ; elles doivent suivre une règle de base un ensemble de lignes directrices spécifiques ce qui (entre autres restrictions) signifie que vous ne pouvez pas inclure des éléments de requête courants tels que COUNT , MIN , MAX ou TOP .
2. Les vues indexées utilisent de l'espace physique dans la base de données, tout comme les index sur une table.

Cet article décrit d'autres avantages et limites des vues indexées :

Vous pouvez

• La définition de la vue peut faire référence à une ou plusieurs tables dans la base de données de l'entreprise. même base de données.
• Une fois que l'index clusterisé unique est créé, des index non clusterisés supplémentaires peuvent être créés. peuvent être créés contre la vue.
• Vous pouvez mettre à jour les données dans les tables sous-jacentes, y compris les insertions, les mises à jour, les suppressions, et même les troncatures.

Vous ne pouvez pas

• La définition de la vue ne peut pas faire référence à d'autres vues ou tables. dans d'autres bases de données.
• Il ne peut pas contenir COUNT, MIN, MAX, TOP, des jointures externes, ou quelques autres mots-clés ou éléments.
• Vous ne pouvez pas modifier les tables et les colonnes sous-jacentes. La vue est créée avec l'option WITH SCHEMABINDING.
• Vous ne pouvez pas toujours prévoir ce que fera l'optimiseur de requêtes. Si vous utilisez Enterprise Edition, il prendra automatiquement en compte l'index unique en unique en cluster comme une option pour une requête, mais s'il trouve un "meilleur" index, celui-ci sera utilisé. meilleur" index, il l'utilisera. Vous pouvez forcer l'optimiseur à utiliser l'index par le biais de l'indice WITH NOEXPAND - mais soyez prudent lorsque vous utilisez un indice de type indice.

Answer 3

EDIT : J'avais tort, et vous devriez voir Marques réponse ci-dessus.

Je ne peux pas parler d'expérience avec SQL Server mais pour la plupart des bases de données, la réponse est non. Le seul avantage potentiel de l'utilisation d'une vue, en termes de performances, est qu'elle peut 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 standardiser une façon d'accéder à certaines données dans une table. En règle générale, vous n'obtiendrez pas d'avantage en termes de performances. Mais je peux me tromper.

Je trouverais un exemple un peu plus compliqué et je le chronométrerais moi-même pour voir.

Answer 4

Dans SQL Server au moins, les plans de requête sont stockés dans le cache de plan pour les vues et les requêtes SQL ordinaires, sur la base des paramètres de la requête/vue. Dans les deux cas, ils sont supprimés du cache lorsqu'ils n'ont pas été utilisés pendant une période suffisamment longue et que 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 aucune 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.

De toute évidence, en général, une vue, de par sa nature même (quelqu'un a pensé qu'elle serait utilisée suffisamment souvent pour en faire une vue), est généralement plus susceptible d'être "réutilisée" que n'importe quelle instruction SQL arbitraire.

Answer 5

Cela peut être plus rapide si vous créez une vue matérialisée ( avec liaison de schéma ). Les vues non matérialisées s'exécutent comme les requêtes ordinaires.