Une vue fonctionne comme un tableau , mais ce n'est pas un tableau. Il n'existe jamais; il s'agit uniquement d'une instruction SQL préparée qui est exécutée lorsque vous référencez le nom de la vue. C'est-à-dire :
CREATE VIEW foo AS
SELECT * FROM bar
SELECT * FROM foo
... équivaut à exécuter :
SELECT x.*
FROM (SELECT * FROM bar) x
Un MySQLDump ne contiendra jamais de lignes à insérer dans une vue...
Cela, malheureusement, est par conception (quoique discutable). Il existe de nombreuses limitations pour les vues MySQL, qui sont documentées :http ://dev.mysql.com/doc/refman/5.0/en/create-view.html
Donc, s'il ne s'agit que d'une table/instruction préparée imaginaire, cela signifie-t-il qu'il a théoriquement les mêmes performances (ou même moins) qu'une table/requête normale ?
Non.
Une table peut être associée à des index, ce qui peut accélérer la récupération des données (moyennant un certain coût pour l'insertion/la mise à jour). Certaines bases de données prennent en charge les vues "matérialisées", qui sont des vues auxquelles des index peuvent être appliqués - ce qui ne devrait pas être une surprise que MySQL ne supporte pas compte tenu de la fonctionnalité d'affichage limitée (qui n'a commencé que dans la v5 IIRC, très tard dans le jeu).
Étant donné qu'une vue est une table dérivée, les performances de la vue ne dépendent que de la requête sur laquelle elle est construite. Si cette requête est nulle, le problème de performances ne fera que boule de neige... Cela dit, lors de l'interrogation d'une vue - si une référence de colonne de vue dans la clause WHERE n'est pas enveloppée dans une fonction (IE :WHERE v.column LIKE ... , pas WHERE LOWER(t.column) LIKE ... ), l'optimiseur peut pousser les critères (appelés prédicat) sur la requête d'origine, ce qui la rend plus rapide.
