Les vues dans MySQL ne sont pas indexées et, par leur nature même, nécessitent une analyse complète à chaque accès. D'une manière générale, cela rend les vues vraiment utiles uniquement dans les situations où vous avez une requête statique assez complexe qui renvoie un petit ensemble de résultats et vous prévoyez de récupérer l'ensemble des résultats à chaque fois.
Modifier : Bien sûr, les vues utiliseront les index sur les tables sous-jacentes afin que la vue elle-même soit optimisée (sinon, leur utilisation n'aurait aucun sens), mais comme il n'y a pas d'index sur une vue, il n'est pas possible pour une requête WHERE sur la vue à optimiser.
Construire des index pour les vues serait de toute façon coûteux car même si je n'ai pas essayé de profiler des vues, je suis à peu près certain qu'une table temporaire est construite dans les coulisses, puis le jeu de résultats est renvoyé. Il faut déjà beaucoup de temps pour construire la table temporaire, je ne voudrais pas d'une vue qui essaie également de deviner quels index sont nécessaires. Ce qui soulève le deuxième point, à savoir que MySQL n'offre pas actuellement de méthode pour spécifier les index à utiliser pour une vue, alors comment sait-il quels champs doivent être indexés ? Est-ce qu'il devine en fonction de votre requête ?
Vous pourriez envisager d'utiliser une table temporaire car vous pouvez alors spécifier des index sur les champs de la table temporaire. Cependant, d'expérience, cela a tendance à être très, très lent.
Si tout ce que contient cette vue est un SELECT ALL FROM table1, table2, table3; alors je devrais demander pourquoi cette requête doit être dans une vue du tout? Si, pour une raison quelconque, c'est absolument nécessaire, vous pouvez utiliser une procédure stockée pour encapsuler la requête, car vous pourrez alors obtenir des performances optimisées tout en conservant l'avantage d'un appel plus simple à la base de données pour le jeu de résultats.
