Una vista funciona como una tabla , pero no es una mesa. Nunca existe; es solo una declaración SQL preparada que se ejecuta cuando hace referencia al nombre de la vista. ES:
CREATE VIEW foo AS
SELECT * FROM bar
SELECT * FROM foo
...es equivalente a ejecutar:
SELECT x.*
FROM (SELECT * FROM bar) x
Un MySQLDump nunca contendrá filas para insertar en una vista...
Eso, lamentablemente, es por diseño (aunque cuestionable). Existen numerosas limitaciones para las vistas de MySQL, que están documentadas:http://dev.mysql.com/doc/refman/5.0/en/create-view.html
Entonces, si es solo una tabla imaginaria/declaración preparada, ¿significa eso que teóricamente tiene el mismo rendimiento (o incluso menos) que una tabla/consulta normal?
No.
Una tabla puede tener índices asociados, lo que puede hacer que la recuperación de datos sea más rápida (con algún costo de inserción/actualización). Algunas bases de datos admiten vistas "materializadas", que son vistas a las que se les pueden aplicar índices, lo que no debería sorprender que MySQL no admita dada la funcionalidad de vista limitada (que solo comenzó en v5 IIRC, muy tarde en el juego).
Debido a que una vista es una tabla derivada, el rendimiento de la vista es tan bueno como la consulta en la que se basa. Si esa consulta apesta, el problema de rendimiento simplemente aumentará... Dicho esto, al consultar una vista, si una referencia de columna de vista en la cláusula WHERE no está envuelta en una función (IE:WHERE v.column LIKE ... , no WHERE LOWER(t.column) LIKE ... ), el optimizador puede insertar los criterios (llamados predicados) en la consulta original, haciéndola más rápida.
