E.5. Ограничения на Представления

Обработка представления не оптимизируется:

Не возможно создать индексирование на представлении.
Индексирует может использоваться для представлений, обработанных, используя алгоритм слияния. Однако, представление, которое обрабатывается с поддающимся соблазну алгоритмом, неспособно использовать в своих интересах, индексирует на его базовых таблицах (хотя индексирует, может использоваться во время генерации временных таблиц).

Подзапросы не могут использоваться в FROM пункт представления.

Есть общий принцип, что невозможно изменить таблицу и выбрать из той же самой таблицы в подзапросе. См. Раздел E.4, "Ограничения на Подзапросы".

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

CREATE VIEW v1 ASSELECT * FROM t2 WHERE EXISTS (SELECT 1 FROM t1 WHERE t1.a = t2.a);UPDATE t1, v2 SET t1.a = 1 WHERE t1.b = v2.b;

Если представление оценивается, используя временную таблицу, можно выбрать из таблицы в представлении, подзапрашивают и все еще изменяют ту таблицу во внешнем запросе. В этом случае представление будет сохранено во временной таблице, и таким образом Вы действительно не выбираете из таблицы в подзапросе и изменяете ее "одновременно." (Это - другая причина, Вы могли бы хотеть вынудить MySQL использовать поддающийся соблазну алгоритм, определяя ALGORITHM = TEMPTABLE в определении представления.)

Можно использовать DROP TABLE или ALTER TABLE отбросить или изменить таблицу, которая используется в определении представления. Никакое предупреждение не следует DROP или ALTER работа, даже при том, что это лишает законной силы представление. Вместо этого ошибка происходит позже, когда представление используется. CHECK TABLE может использоваться, чтобы проверить на представления, которые были лишены законной силы DROP или ALTER операции.

Определение представления "замораживается" определенными операторами:

Если оператор, подготовленный PREPARE обращается к представлению, определению представления, замеченному каждый раз, когда оператор выполняется, позже будет определение представления в то время, когда это было подготовлено. Это - истина, даже если определение представления изменяется после того, как оператор готовится и прежде, чем это будет выполнено. Пример:
```
CREATE VIEW v AS SELECT RAND();PREPARE s FROM 'SELECT * FROM v';ALTER VIEW v AS SELECT NOW();EXECUTE s;
```
Результат, возвращенный EXECUTE оператор является случайным числом, не текущей датой и время.

Относительно представления updatability, полная цель для представлений состоит в том, что, если какое-либо представление теоретически обновляемо, это должно быть обновляемо практически. Это включает представления, которые имеют UNION в их определении. В настоящий момент не все представления, которые теоретически обновляемы, могут быть обновлены. Начальная реализация представления была сознательно записана этот способ получить применимые, обновляемые представления в MySQL как можно быстрее. Много теоретически обновляемых представлений могут быть обновлены теперь, но ограничения все еще существуют:

Обновляемые представления с подзапросами где угодно кроме в WHERE пункт. Некоторые представления, у которых есть подзапросы в SELECT список может быть обновляемым.
Невозможно использовать UPDATE обновить больше чем одну базовую таблицу представления, которое определяется как соединение.
Невозможно использовать DELETE обновить представление, которое определяется как соединение.

Там существует недостаток с текущей реализацией представлений. Если пользователю предоставляют основные полномочия, необходимые, чтобы создать представление ( CREATE VIEW и SELECT полномочия), тот пользователь будет неспособен вызвать SHOW CREATE VIEW на том объекте, если пользователя также не предоставляют SHOW VIEW полномочие.

Тот недостаток может привести к проблемам, поддерживая базу данных с mysqldump, который может перестать работать из-за недостаточных полномочий. Эта проблема описывается в Ошибке #22062.

Обходное решение к проблеме для администратора, чтобы вручную предоставить SHOW VIEW полномочие пользователям, которых предоставляют CREATE VIEW, так как MySQL не предоставляет это неявно, когда представления создаются.

Представления не имеют, индексирует, так индексируйте подсказки, не применяются. Использование индексирует подсказки, когда выбор из представления не разрешается.

SHOW CREATE VIEW дисплеи просматривают определения, используя AS alias_name пункт для каждого столбца. Если столбец создается из выражения, псевдоним значения по умолчанию является текстом выражения, который может быть довольно длинным. Псевдонимы для имен столбцов в CREATE VIEW операторы проверяются по максимальной длине столбца 64 символов (не максимальная длина псевдонима 256 символов). В результате представления, создаваемые из вывода SHOW CREATE VIEW перестаньте работать, если какой-либо псевдоним столбца превышает 64 символа. Это может вызвать проблемы при следующих обстоятельствах для представлений со слишком длинными псевдонимами:

Определения представления не в состоянии тиражироваться к более новым ведомым устройствам, которые осуществляют ограничение длиной до столбца.
Файлы дампа, создаваемые с mysqldump, не могут быть загружены в серверы, которые осуществляют ограничение длиной до столбца.

Обходное решение для любой проблемы является изменением каждого проблематичного определения представления, чтобы использовать псевдонимы, которые обеспечивают более короткие имена столбцов. Затем представление тиражируется должным образом, и может быть выведено и перезагружено, не вызывая ошибку. Чтобы изменить определение, отбросьте и создайте представление снова с DROP VIEW и CREATE VIEW, или замените определение CREATE OR REPLACE VIEW.

Для проблем, которые происходят, перезагружая определения представления в файлах дампа, другое обходное решение должно отредактировать файл дампа, чтобы изменить CREATE VIEW операторы. Однако, это не изменяет исходные определения представления, которые могут вызвать проблемы для последующих операций дампа.