Lors de la création de tables à partir de plusieurs jointures pour une utilisation dans l'analyse, quand est-il préférable d'utiliser des vues plutôt que de créer une nouvelle table?
L'une des raisons pour lesquelles je préférerais utiliser les 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 la création de tables, mais nécessite une étape supplémentaire et j'aimerais 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 la plus votée commence "faites le manipulations de données dans SQL jusqu'à ce que les données soient dans une seule table, puis faites le reste dans R. "
J'ai commencé à utiliser des vues, mais j'ai rencontré quelques problèmes avec les vues:
Les vues sont-elles appropriées pour cette utilisation? Si oui, dois-je m'attendre à une pénalité de performance? Existe-t-il un moyen d'accélérer les requêtes sur les vues?
Les vues dans MySQL sont gérées en utilisant l'un des deux algorithmes différents: MERGE
ou TEMPTABLE
. MERGE
est simplement une extension de requête avec des alias appropriés. TEMPTABLE
est exactement ce à quoi cela ressemble, la vue place les résultats dans une table temporaire avant d'exécuter la clause WHERE, et il n'y a pas d'index dessus.
La "troisième" option est UNDEFINED
, qui indique à MySQL de sélectionner l'algorithme approprié. MySQL tentera d'utiliser MERGE
car il est plus efficace. Avertissement principal:
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)
Je me risquerais à deviner que vos VUES nécessitent l'algorithme TEMPTABLE, provoquant des problèmes de performances.
Voici un très ancien article 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 à la fin du tunnel sur ce problème des tables temporaires ne contenant pas d'index (provoquant des analyses complètes des tables). Dans 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 avoir ajouté 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 il bénéficie de la même manière de l'index généré. Les frais généraux de création d'index sont négligeables par rapport au coût de l'exécution des requêtes sans l'index.
Comme le souligne @ypercube, MariaDB 5.3 a ajouté la même optimisation. Cet article a un aperçu intéressant du processus:
L'optimisation est appliquée, puis la table dérivée n'a pas pu être fusionnée dans son parent SELECT, ce qui se produit lorsque la table dérivée ne répond pas aux critères de VIEW fusionnable
Les vues sont des outils de sécurité. Vous ne voulez pas qu'un utilisateur ou une application particulière sache où se trouve votre table de données, vous fournissez une vue avec uniquement les colonnes dont il a besoin.
N'oubliez pas que les vues dégradent toujours les performances, des requêtes similaires doivent être des procédures et des fonctions stockées, pas des vues.
Pour effectuer un réglage de requête, 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 les insertions, les mises à jour et les suppressions.
Il existe une bonne documentation qui peut vous aider: http://www.toadworld.com/LinkClick.aspx?fileticket=3qbwCnzY/0A=&tabid=234