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

Question

Когда я создаю представление, я в основном создаю новую таблицу, которая будет автоматически обрабатываться при изменении данных в одной из таблиц, к которым она присоединяется; это правильно?

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

Answer 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 не поддерживает , учитывая ограниченную функциональность представлений (которая началась только в v5 IIRC , очень поздно к игре).

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

Answer 2

Разница:

для просмотра вы можете иметь только подзапросы в части where, а не в части from, поэтому

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

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

Answer 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' (представление) в основном является простым представлением только моих самых последних версий каждой записи. Кажется, сейчас все в порядке!

Обновление:

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

Также, если вы прочитали 17.5.1. Просмотрите синтаксис раздел, он четко гласит:

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

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