Quand utiliser les vues dans MySQL?

Lors de la création de tables à partir de plusieurs jointures à utiliser dans l'analyse, à quel moment est-il préférable d'utiliser des vues plutôt que de créer une nouvelle table?

Une des raisons pour lesquelles je préférerais utiliser des vues est que le schéma de base de données a été développé par notre administrateur à partir de Ruby, et je ne connais pas Ruby. Je peux demander que des tables soient créées, mais nécessite une étape supplémentaire et je voudrais plus de flexibilité lors du développement / test de nouvelles jointures.

J'ai commencé à utiliser des vues après la réponse à une question connexe sur SO ( Quand utiliser R, quand utiliser SQL ). La réponse votée par le haut commence par "Effectuez les manipulations de données en SQL jusqu'à ce que les données se trouvent dans une seule table, puis faites le reste en R."

J'ai commencé à utiliser des vues, mais j'ai rencontré quelques problèmes avec les vues:

1. les requêtes sont beaucoup plus lentes
2. Les vues ne sont pas transférées de la production vers la base de données de sauvegarde que j'utilise pour l'analyse.

Les vues sont-elles appropriées pour cet usage? Si oui, devrais-je m'attendre à une pénalité de performance? Est-il possible d'accélérer les requêtes sur les vues?

Les vues dans MySQL sont gérées à l'aide de deux algorithmes différents: MERGEou TEMPTABLE. MERGEest simplement une extension de requête avec des alias appropriés. TEMPTABLELa vue place les résultats dans une table temporaire avant d'exécuter la clause WHERE et ne contient aucun index.

La troisième option est UNDEFINED, qui indique à MySQL de sélectionner l'algorithme approprié. MySQL tentera de l'utiliser MERGEcar il est plus efficace. Mise en garde principale:

Si l'algorithme MERGE ne peut pas être utilisé, une table temporaire doit être utilisée à la place. MERGE ne peut pas être utilisé si la vue contient l'une des constructions suivantes:

• Fonctions d'agrégation (SUM (), MIN (), MAX (), COUNT (), etc.)

• DISTINCT

• PAR GROUPE

• AYANT

• LIMITE

• UNION ou UNION ALL

• Sous-requête dans la liste de sélection

• Fait uniquement référence aux valeurs littérales (dans ce cas, il n'y a pas de table sous-jacente)

[src]

Je me risquerais à deviner que vos points de vue exigent l’algorithme TEMPTABLE, ce qui pose des problèmes de performances.

Voici un très vieux billet de blog sur les performances des vues dans MySQL et il ne semble pas s’être amélioré.

Cependant, il pourrait y avoir un peu de lumière au bout du tunnel sur cette question des tables temporaires ne contenant pas d’index (provoquant des analyses complètes de table). En 5.6 :

Dans les cas où la matérialisation est requise pour une sous-requête dans la clause FROM, l'optimiseur peut accélérer l'accès au résultat en ajoutant un index à la table matérialisée. ... Après l'ajout de l'index, l'optimiseur peut traiter la table dérivée matérialisée de la même manière qu'une table habituelle avec un index, et bénéficie de la même manière de l'index généré. Le surcoût de la création d'index est négligeable par rapport au coût d'exécution d'une requête sans l'index.

Comme @ypercube le fait remarquer, MariaDB 5.3 a ajouté la même optimisation. Cet article présente un aperçu intéressant du processus:

L'optimisation est appliquée, puis la table dérivée ne peut pas être fusionnée dans son SELECT SELECT parent, ce qui se produit lorsque la table dérivée ne remplit pas les critères de VIEW fusionnable.

Les vues sont des outils de sécurité. Vous ne voulez pas qu'un utilisateur ou une application en particulier sache où se trouve votre table de données, vous fournissez une vue avec uniquement les colonnes dont elle a besoin.

N'oubliez pas que les vues dégradent toujours les performances. Les requêtes similaires doivent être des procédures et des fonctions stockées, et non des vues.

Pour optimiser les requêtes, suivez toujours les meilleures pratiques, évitez d’utiliser des fonctions dans les clauses WHERE, créez des index pour accélérer les sélections, mais n’en abusez pas, les index dégradent, insèrent, mettent à jour et suppriment.

Il existe une bonne documentation pouvant vous aider: http://www.toadworld.com/LinkClick.aspx?fileticket=3qbwCnzY/0A=&tabid=234

Je pense que les vues sont la structure prédéfinie (pas de données) pour la fusion de tables en une à surmonter à partir de requêtes de table multiples, qui peuvent être utilisées à partir de données réelles pour des requêtes relationnelles rapides ...