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

Возможная будущая оптимизация: подзапрос в предложении FROM оценен, осуществляя результат во временную таблицу, и эта таблица не использует индексы. Это не позволяет использование индексов по сравнению с другими таблицами в запросе, хотя это могло бы быть полезно.

Возможная будущая оптимизация: если подзапрос в предложении FROM походит на просмотр, к которому может применяться объединяющийся алгоритм, переписать запрос и применить объединяющийся алгоритм так, чтобы индексы могли использоваться. Следующая инструкция содержит такой подзапрос:

SELECT * FROM (SELECT * FROM t1 WHERE t1.t1_col) AS _t1, t2 WHERE t2.t2_col;

Инструкция может быть переписана как объединение подобно этому:

SELECT * FROM t1, t2 WHERE t1.t1_col AND t2.t2_col;

Этот тип перезаписи обеспечил бы две выгоды:

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

Это дает оптимизатору большее количество свободы выбрать между различными планами выполнения. Например, перезапись запроса как объединения позволяет оптимизатору использовать сначала 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, используя объединяющий алгоритм. Однако, 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;