Eine Ansicht funktioniert wie eine Tabelle , aber es ist keine Tabelle. Es existiert nie; es ist nur eine vorbereitete SQL-Anweisung, die ausgeführt wird, wenn Sie auf den Ansichtsnamen verweisen. IE:
CREATE VIEW foo AS
SELECT * FROM bar
SELECT * FROM foo
...entspricht dem Ausführen von:
SELECT x.*
FROM (SELECT * FROM bar) x
Ein MySQLDump wird niemals Zeilen enthalten, die in eine Ansicht eingefügt werden sollen...
Das ist leider ein (wenn auch fragwürdiges) Design. Es gibt zahlreiche Einschränkungen für MySQL-Ansichten, die dokumentiert sind:http://dev.mysql.com/doc/refman/5.0/en/create-view.html
Wenn es sich also nur um eine imaginäre Tabelle/vorbereitete Anweisung handelt, bedeutet das, dass sie theoretisch dieselbe Leistung (oder sogar weniger) wie eine normale Tabelle/Abfrage hat?
Nein.
Einer Tabelle können Indizes zugeordnet sein, was den Datenabruf beschleunigen kann (zu einem gewissen Preis für das Einfügen/Aktualisieren). Einige Datenbanken unterstützen "materialisierte" Ansichten, das sind Ansichten, auf die Indizes angewendet werden können - was keine Überraschung sein sollte, dass MySQL keine Unterstützung bietet angesichts der eingeschränkten Ansichtsfunktionalität (die erst in v5 IIRC begann, sehr spät im Spiel).
Da eine Sicht eine abgeleitete Tabelle ist, ist die Leistung der Sicht nur so gut wie die Abfrage, auf der sie aufbaut. Wenn diese Abfrage scheiße ist, wird das Leistungsproblem einfach Schneeball ... Das heißt, wenn eine Ansicht abgefragt wird - wenn eine Ansichtsspaltenreferenz in der WHERE-Klausel nicht in eine Funktion eingeschlossen ist (IE:WHERE v.column LIKE ... , nicht WHERE LOWER(t.column) LIKE ... ), kann der Optimierer die Kriterien (als Prädikat bezeichnet) auf die ursprüngliche Abfrage übertragen, wodurch sie schneller wird.
