Максимальное количество таблиц, которые могут быть упомянуты в определении представления, составляет 61.

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

Существует общее правило: нельзя изменять таблицу и выбирать данные из той же таблицы в подзапросе. См. Раздел 15.2.15.12 «Ограничения на подзапросы».

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

CREATE VIEW v1 AS
SELECT * 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.

Что касается возможности обновления представлений, общей целью для представлений является то, что если какое-либо представление теоретически обновляемо, оно должно быть обновляемо на практике. Многие теоретически обновляемые представления сейчас могут быть обновлены, но ограничения все еще существуют. Подробнее см. Раздел 27.6.3 «Обновляемые и вставляемые представления».

В текущей реализации представлений есть недостаток. Если пользователю предоставлены базовые привилегии для создания представления (привилегии 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 символа. Это может вызвать проблемы в следующих ситуациях для представлений с слишком длинными псевдонимами:

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

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