Как работают представления MySQL?

Ответ 1

Вид работает как таблица, но это не таблица. Он никогда не существует; это только подготовленный оператор SQL, который запускается, когда вы ссылаетесь на имя представления. IE:

CREATE VIEW foo AS
  SELECT * FROM bar

SELECT * FROM foo

... эквивалентно запуску:

SELECT x.* 
  FROM (SELECT * FROM bar) x

MySQLDump никогда не будет содержать строки, которые нужно вставить в представление...

Также почему я не могу использовать подзапросы в моем представлении????

Это, к сожалению, по (хотя и сомнительному) дизайну. Существуют многочисленные ограничения для представлений MySQL, которые документированы: http://dev.mysql.com/doc/refman/5.0/en/create-view.html

Итак, если это только воображаемая таблица/подготовленный оператор, это означает, что теоретически она имеет такую ​​же производительность (или даже меньше) как обычную таблицу/запрос?

Нет.
Таблица может иметь ассоциированные индексы, которые могут быстрее извлекать данные (при некоторой стоимости для вставки/обновления). Некоторые базы данных поддерживают "материализованные" представления, которые представляют собой представления, которые могут иметь индексы, применяемые к ним, что не должно удивлять, что MySQL не поддерживает, учитывая ограниченную функциональность представления (которая началась только в версии 5 IIRC, очень поздно к игре).

Поскольку представление представляет собой производную таблицу, производительность представления только так хороша, как запрос, на котором он построен. Если этот запрос засасывает, проблема с производительностью будет только снегом... При этом при запросе представления - если ссылка на столбец представления в предложении WHERE не обернута в функцию (IE: WHERE v.column LIKE ..., not WHERE LOWER(t.column) LIKE ...), оптимизатор может подталкивать критерии (называемые предикатами) к исходному запросу - делая его быстрее.

Ответ 2

Разница заключается в следующем:

для просмотра у вас могут быть только подзапросы в части где-части, а не в части, поэтому

CREATE VIEW v AS SELECT * FROM foo WHERE id IN (SELECT id FROM bar) 

будет работать, но в то же время вы получите представление только для чтения... Простой вид в одной таблице позволит обновить "через" представление к базовой таблице

Ответ 3

Я столкнулся с той же проблемой (к моему удивлению, потому что мой поиск показывает, что Oracle и MS поддерживают его).

Я обойду это ограничение (по крайней мере пока, пока не будет доказано, что не используется), создав два дополнительных представления для моего окончательного вида.

Пример:

CREATE VIEW Foo1 AS
    SELECT * FROM t ORDER BY ID, InsertDate DESC

CREATE VIEW Foo2 AS
    SELECT * FROM Foo1 GROUP BY ID

CREATE VIEW Foo AS
    SELECT * FROM Foo2 ORDER BY ID

В приведенном выше примере в основном есть таблица 't', которая представляет собой временную таблицу, содержащую все ревизии. Мой "Foo" (просмотр) в основном представляет собой простой взгляд только на мои самые последние версии каждой записи. Кажется, сейчас все в порядке!

Update:

Я не знаю, является ли это еще одной ошибкой в ​​MySQL 5.1, но приведенный выше пример на самом деле не работает! "Foo1" работает так, как ожидалось, но "Foo2", похоже, игнорирует порядок до группировки, поэтому мой конечный результат не является тем, что предполагается. Я даже получаю тот же результат, если я изменил "DESC" для "ASC" (удивительно).

Кроме того, если вы читаете 17.5.1. См. Раздел "Синтаксис", в нем четко указано:

"Вид может быть создан из многих видов операторов SELECT, он может ссылаться на базовые таблицы или другие представления. Он может использовать объединения, UNION и подзапросы."

Я собираюсь обновить мою базу данных до 5.6 и повторить попытку!