Performances des vues MySql

Question

Si vous décidez d'utiliser des vues, comment pouvez-vous garantir de bonnes performances ?

Ou est-il préférable de ne pas utiliser les vues en premier lieu et d'incorporer l'équivalent dans vos déclarations de sélection ?

Answer 1

Cela dépend.

Cela dépend totalement de ce que vous regardez à travers la vue. Mais il est fort probable que cela réduise vos efforts et améliore les performances. Lorsqu'une instruction SQL fait référence à une vue non indexée, l'analyseur syntaxique et l'optimiseur de requêtes 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 séparé pour la vue.

Une vue n'est pas compilée . Il s'agit d'une table virtuelle composée d'autres tables. Lorsque vous la créez, elle ne réside pas quelque part sur votre serveur. Les requêtes sous-jacentes qui composent la vue sont sujettes aux mêmes gains de performance ou aux mêmes problèmes de l'optimiseur de requêtes. Je n'ai jamais testé les performances d'une vue VS 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 à quoi vous pensez en termes de "compilé".

Avantages des vues :

1. Visualiser les données sans les stocker dans l'objet.
2. Restreindre la vue d'un tableau, c'est-à-dire masquer certaines colonnes dans les tableaux.
3. Joindre deux ou plusieurs tables et les présenter comme un seul objet à l'utilisateur.
4. Restreindre l'accès à un tableau de manière à ce que personne ne puisse y insérer des lignes.

Voir ces liens utiles :

1. Performance d'une VIEW par rapport à une instruction SQL
2. Une vue est-elle plus rapide qu'une simple requête ?
3. VIEWS Mysql vs. requête PHP
4. Les vues MySql sont-elles dynamiques et efficaces ?
5. Vue matérialisée vs. tables : Quels sont les avantages ?
6. L'interrogation d'une vue est-elle plus lente que l'exécution directe d'une requête SQL ?
7. Une solution pour résoudre les problèmes de performance des vues TEMPTABLE
8. Gagner en performance en utilisant les vues indexées dans SQL Server

Answer 2

Vous pouvez trouver des évaluations détaillées auprès de Peter Zaitsev et d'autres sources.

Les vues dans MySQL sont généralement une mauvaise idée. Chez Grooveshark, nous les considérons comme nuisibles et les évitons toujours. Si vous êtes prudent, vous pouvez les faire fonctionner, mais dans le meilleur des cas, elles sont un moyen de se rappeler comment sélectionner des données ou de vous éviter d'avoir à retaper des jointures compliquées. Dans le pire des cas, ils peuvent provoquer des inefficacités massives, masquer la complexité, provoquer des sous-sélections imbriquées accidentelles (nécessitant des tables temporaires et conduisant à l'utilisation du disque), etc.

Il est préférable de les éviter et de conserver vos requêtes dans le code.

Answer 3

Je pense que le blog de Peter Zaitsev contient la plupart des détails. D'après mon expérience personnelle, les vues peuvent donner de bons résultats si elles restent simples. Chez l'un de mes clients, on n'arrêtait pas de superposer des vues les unes sur les autres et cela s'est terminé par un cauchemar en termes de performances.

En général, j'utilise les vues pour montrer un aspect différent d'une table. Par exemple, dans mon tableau des employés, affichez les responsables ou masquez le champ du salaire pour les employés qui ne font pas partie des RH. Veillez également à toujours exécuter une EXPLAIN sur la requête et la vue pour comprendre exactement ce qui se passe dans MySQL.

Si vous voulez une preuve solide de votre scénario, je vous suggère de faire un test. Il est vraiment difficile de dire que l'utilisation des vues est toujours un tueur de performance, mais encore une fois, une vue mal écrite va probablement tuer votre performance.

Answer 4

Elles ont leur utilité, mais les complexités cachées et les inefficacités l'emportent généralement sur une approche plus directe. J'ai un jour rencontré une instruction SQL qui joignait deux vues et triait les résultats. Les vues étaient également triées, de sorte que le temps d'exécution pouvait être mesuré en ce qui semblait être des heures.

Answer 5

Une chose qui n'a pas été mentionnée jusqu'à présent mais qui fait une énorme différence est l'indexation adéquate des points de vue source tables .

Comme indiqué plus haut, les vues ne résident pas dans votre base de données mais sont reconstruire à chaque fois . Ainsi, tout ce qui facilite la reconstruction pour la base de données augmente les performances de la vue.

Souvent, les vues joignent des données d'une manière qui est très mauvaise pour le stockage (pas de forme normale) mais très bonne pour l'utilisation ultérieure (analyse, présentation des données à l'utilisateur, ...) et, par conséquent, joignent et agrègent des données provenant de différentes tables.

Le fait que les colonnes sur lesquelles les opérations sont effectuées soient indexées ou non a une incidence considérable sur les performances d'une vue. Si les tables et les colonnes correspondantes sont déjà indexées, l'accès à la vue ne nécessite pas de recalculer les index à plusieurs reprises. . (d'un autre côté, cela se fait lorsque les données sont manipulées dans les tables sources).

! Indexez toutes les colonnes utilisées dans les clauses JOINS et GROUP BY de votre déclaration CREATE VIEW !