объединения позволяет оптимизатору использовать сначала t1 или t2.
Возможная будущая оптимизация: для IN, = ANY, <> ANY, = ALL и <> ALL с не соотнесенными подзапросами использовать в оперативной памяти хэш для результата или временную таблицу с индексом для больших результатов. Пример:
SELECT a FROM big_table AS bt WHERE non_key_field IN (SELECT non_key_field FROM table WHERE condition)
В этом случае мы могли бы создавать временную таблицу:
CREATE TABLE t (key (non_key_field)) (SELECT non_key_field FROM table WHERE condition)
Затем для каждой строки в big_table сделайте поисковую таблицу ключа в t, основываясь на bt.non_key_field.
Невозможно создать индекс на view.
Индексы могут использоваться для обработанных view, используя объединяющий алгоритм. Однако, view, который обработан алгоритмом temptable, не способен пользоваться преимуществом индексов на основных таблицах (хотя индексы могут использоваться в течение поколения временных таблиц).
Подзапросы не могут использоваться в предложении FROM view. Это ограничение будет сниматься в будущем.
Имеется общий принцип, что Вы не можете изменять таблицу и выбирать из той же самой таблицы в подзапросе.
Тот же самый принцип также применяется, если Вы выбираете из view, который выбирает из таблицы, если выбор view из таблицы в подзапросе и view оценены, используя объединяющий алгоритм. Пример:
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;
Если view оценен, используя временную таблицу, Вы можете выбирать из таблицы в view подзапросом и менятт ту таблицу во внешнем запросе. В этом случае view будет сохранен во временной таблице, и таким образом Вы действительно не выбираете из таблицы в подзапросе и изменяете таблицу в то же самое время. Можно принудительно предписать MySQL использовать алгоритм temptable, определяя ALGORITHM = TEMPTABLE в определении view.
Вы можете использовать DROP TABLE или ALTER TABLE, чтобы удалять или изменять таблицу, которая используется в определении view (это объявляет неверным view), и никакого предупреждения не последует. Ошибка происходит позже, когда view используется.
Определение view заморожено некоторыми инструкциями:
Если инструкция, подготовленная PREPARE, обращается к view, то содержание этого view какждый раз при выполнении инструкции будет точно соответствовать моменту ее подготовки. Это истинно, даже если определение view изменен после того, как инструкция подготовлена, но прежде, чем она выполнена. Пример:
CREATE VIEW v AS SELECT 1; PREPARE s FROM 'SELECT * FROM v'; ALTER VIEW v AS SELECT 2; EXECUTE s;
Результат, возвращенный инструкцией EXECUTE, 1, а не 2.
Если инструкция в сохраненной подпрограмме обращается к view, содержание view точно такое же, как в первый раз, когда инструкция выполнена. Например, это означает, что, если инструкция выполнена в цикле, дальнейшие итерации инструкции видят то же самое содержание view, даже если определение view изменено позже в цикле. Пример:
CREATE VIEW v AS SELECT 1; delimiter // CREATE PROCEDURE p () BEGIN DECLARE i INT DEFAULT 0; WHILE i < 5 DO SELECT * FROM v; SET i = i + 1; ALTER VIEW v AS SELECT 2; END WHILE; END; // delimiter ; CALL p();
Когда процедура p() вызвана, SELECT возвращает 1 каждый раз в цикле, даже при том, что определение view изменено внутри цикла.
Относительно обновляемых view: полная цель для view состоит в том, что, если любой view является теоретически обновляемым, это должно быть обновляемым и практически. Это включает view, которые имеют UNION в их определении. В настоящее время не все просмотры, которые являются теоретически обновляемыми, таковы на деле (могут модифицироваться). Начальная реализация view была преднамеренно написана этим способом, чтобы стать пригодной для использования, обновляемые view в MySQL будут сделаны настолько быстро, насколько возможно. Многие теоретически обновляемые view могут модифицироваться теперь, но ограничения все еще существуют:
Обновляемые view с подзапросами где-нибудь не в предложении WHERE. Некоторые view, которые имеют подзапросы в списке SELECT, могут быть обновляемыми.
Вы не можете использовать UPDATE, чтобы модифицировать больше, чем одну основную таблицу view, который определен как объединение.
Вы не можете использовать DELETE, чтобы модифицировать view, который определен как объединение.
Если пользователю предоставляют базисные привилегии, необходимые, чтобы создавать view (привилегии CREATE VIEW и SELECT), этот пользователь будут не способен вызвать SHOW CREATE VIEW на этом объекте, если пользователю не предоставляют также привилегию SHOW VIEW.
Этот недостаток может привести к проблемам при копировании базы данных с помощью mysqldump, которая может терпеть неудачу из-за недостаточных привилегий. Эта проблема описана в Глюке #22062. Обход: чтобы администратор вручную предоставил привилегию SHOW VIEW пользователям, которым предоставляется CREATE VIEW, так как MySQL не предоставляет это неявно, когда создан view.
Возможная будущая оптимизация: для IN, = ANY, <> ANY, = ALL и <> ALL с не соотнесенными подзапросами использовать в оперативной памяти хэш для результата или временную таблицу с индексом для больших результатов. Пример:
SELECT a FROM big_table AS bt WHERE non_key_field IN (SELECT non_key_field FROM table WHERE condition)
В этом случае мы могли бы создавать временную таблицу:
CREATE TABLE t (key (non_key_field)) (SELECT non_key_field FROM table WHERE condition)
Затем для каждой строки в big_table сделайте поисковую таблицу ключа в t, основываясь на bt.non_key_field.
11.4. Ограничения на Views
Обработка View не оптимизирована:Невозможно создать индекс на view.
Индексы могут использоваться для обработанных view, используя объединяющий алгоритм. Однако, view, который обработан алгоритмом temptable, не способен пользоваться преимуществом индексов на основных таблицах (хотя индексы могут использоваться в течение поколения временных таблиц).
Подзапросы не могут использоваться в предложении FROM view. Это ограничение будет сниматься в будущем.
Имеется общий принцип, что Вы не можете изменять таблицу и выбирать из той же самой таблицы в подзапросе.
Тот же самый принцип также применяется, если Вы выбираете из view, который выбирает из таблицы, если выбор view из таблицы в подзапросе и view оценены, используя объединяющий алгоритм. Пример:
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;
Если view оценен, используя временную таблицу, Вы можете выбирать из таблицы в view подзапросом и менятт ту таблицу во внешнем запросе. В этом случае view будет сохранен во временной таблице, и таким образом Вы действительно не выбираете из таблицы в подзапросе и изменяете таблицу в то же самое время. Можно принудительно предписать MySQL использовать алгоритм temptable, определяя ALGORITHM = TEMPTABLE в определении view.
Вы можете использовать DROP TABLE или ALTER TABLE, чтобы удалять или изменять таблицу, которая используется в определении view (это объявляет неверным view), и никакого предупреждения не последует. Ошибка происходит позже, когда view используется.
Определение view заморожено некоторыми инструкциями:
Если инструкция, подготовленная PREPARE, обращается к view, то содержание этого view какждый раз при выполнении инструкции будет точно соответствовать моменту ее подготовки. Это истинно, даже если определение view изменен после того, как инструкция подготовлена, но прежде, чем она выполнена. Пример:
CREATE VIEW v AS SELECT 1; PREPARE s FROM 'SELECT * FROM v'; ALTER VIEW v AS SELECT 2; EXECUTE s;
Результат, возвращенный инструкцией EXECUTE, 1, а не 2.
Если инструкция в сохраненной подпрограмме обращается к view, содержание view точно такое же, как в первый раз, когда инструкция выполнена. Например, это означает, что, если инструкция выполнена в цикле, дальнейшие итерации инструкции видят то же самое содержание view, даже если определение view изменено позже в цикле. Пример:
CREATE VIEW v AS SELECT 1; delimiter // CREATE PROCEDURE p () BEGIN DECLARE i INT DEFAULT 0; WHILE i < 5 DO SELECT * FROM v; SET i = i + 1; ALTER VIEW v AS SELECT 2; END WHILE; END; // delimiter ; CALL p();
Когда процедура p() вызвана, SELECT возвращает 1 каждый раз в цикле, даже при том, что определение view изменено внутри цикла.
Относительно обновляемых view: полная цель для view состоит в том, что, если любой view является теоретически обновляемым, это должно быть обновляемым и практически. Это включает view, которые имеют UNION в их определении. В настоящее время не все просмотры, которые являются теоретически обновляемыми, таковы на деле (могут модифицироваться). Начальная реализация view была преднамеренно написана этим способом, чтобы стать пригодной для использования, обновляемые view в MySQL будут сделаны настолько быстро, насколько возможно. Многие теоретически обновляемые view могут модифицироваться теперь, но ограничения все еще существуют:
Обновляемые view с подзапросами где-нибудь не в предложении WHERE. Некоторые view, которые имеют подзапросы в списке SELECT, могут быть обновляемыми.
Вы не можете использовать UPDATE, чтобы модифицировать больше, чем одну основную таблицу view, который определен как объединение.
Вы не можете использовать DELETE, чтобы модифицировать view, который определен как объединение.
Если пользователю предоставляют базисные привилегии, необходимые, чтобы создавать view (привилегии CREATE VIEW и SELECT), этот пользователь будут не способен вызвать SHOW CREATE VIEW на этом объекте, если пользователю не предоставляют также привилегию SHOW VIEW.
Этот недостаток может привести к проблемам при копировании базы данных с помощью mysqldump, которая может терпеть неудачу из-за недостаточных привилегий. Эта проблема описана в Глюке #22062. Обход: чтобы администратор вручную предоставил привилегию SHOW VIEW пользователям, которым предоставляется CREATE VIEW, так как MySQL не предоставляет это неявно, когда создан view.
