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

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

До MySQL 5.7.7 в предложении FROM представления нельзя использовать подзапросы.

Существует общее правило, согласно которому нельзя модифицировать таблицу и выбирать данные из той же таблицы в подзапросе. См. Раздел 13.2.10.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.

Что касается обновляемости представлений, то общей целью для представлений является то, что если какое-либо представление теоретически обновляемо, то оно должно быть обновляемо на практике. Многие теоретически обновляемые представления могут быть обновлены сейчас, но ограничения всё ещё существуют. Подробности см. в Разделе 23.5.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 предложений. Однако это не меняет исходные определения представлений, что может вызвать проблемы для последующих операций дампов.