En vy fungerar som en tabell , men det är inte ett bord. Den existerar aldrig; det är bara en förberedd SQL-sats som körs när du refererar till vynnamnet. IE:
CREATE VIEW foo AS
SELECT * FROM bar
SELECT * FROM foo
...är likvärdig med att köra:
SELECT x.*
FROM (SELECT * FROM bar) x
En MySQLDump kommer aldrig att innehålla rader som ska infogas i en vy...
Det är tyvärr av (om än tveksamt) design. Det finns många begränsningar för MySQL-vyer, som är dokumenterade:http://dev.mysql.com/doc/refman/5.0/en/create-view.html
Så om det bara är en imaginär tabell/förberedd sats betyder det att den teoretiskt har samma prestanda (eller till och med mindre) som en vanlig tabell/fråga?
Nej.
En tabell kan ha index associerade, vilket kan göra datahämtning snabbare (till viss kostnad för infogning/uppdatering). Vissa databaser stöder "materialiserade" vyer, vilket är vyer som kan ha index applicerade på dem - vilket inte borde vara en överraskning att MySQL inte stöder med tanke på den begränsade visningsfunktionen (som först började i v5 IIRC, mycket sent i spelet).
Eftersom en vy är en härledd tabell är prestandan för vyn bara lika bra som frågan den bygger på. Om den frågan suger, kommer prestandaproblemet bara att snöa... Som sagt, när man frågar en vy - om en vykolumnreferens i WHERE-satsen inte är insvept i en funktion (IE:WHERE v.column LIKE ... , inte WHERE LOWER(t.column) LIKE ... ), kan optimeraren skjuta in kriterierna (kallas ett predikat) till den ursprungliga frågan - vilket gör det snabbare.