Подзапрос IN может быть намного медленнее, чем запрос, написанный с использованием конструкции IN(value_list), которая вносит в список те же самые значения, которые возвратил бы подзапрос.

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

DELETE FROM t WHERE … (SELECT … FROM t …);

UPDATE t … WHERE col = (SELECT … FROM t …);

{INSERT|REPLACE} INTO t (SELECT … FROM t …);

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

UPDATE t … WHERE col = (SELECT (SELECT … FROM t…) AS _t …);

Здесь запрещение не применяется, потому что результат от подзапроса в предложении FROM сохранен как временная таблица, так что релевантные строки в t уже были выбраны ко времени модификации t.

Операции сравнения строк обеспечиваются пока только частично:

Для expr IN (subquery), expr может быть n– кортеж (определенный через синтаксис конструктора строки) и подзапрос может возвращать строки n– кортежей.

Для expr op {ALL|ANY|SOME} (подзапрос), expr должен быть скалярным значением, и подзапрос должен быть подзапросом столбца, это не может возвращать строки с многими столбцами.

Другими словами, для подзапроса, который возвращает строки n– кортежей, это обеспечивается:

(val_1, …, val_n) IN

(subquery)

Но это не обеспечивается:

(val_1, …, val_n)

op {ALL|ANY|SOME} (subquery)

Причина для обеспечения сравнений строки для IN, но не для других: IN выполнен, перезаписывая это как последовательность сравнений = и операций AND. Этот подход не может использоваться для ALL, ANY или SOME.

Конструкторы строк не оптимизированы хорошо. Следующие два выражения эквивалентны, но только второе может быть оптимизировано:

(col1, col2, …) = (val1, val2, …)

col1 = val1 AND col2 = val2 AND …

Подзапросы в предложении FROM не могут быть соотнесены подзапросам. Они осуществлены (выполнены, чтобы произвести набор результатов) перед оценкой внешнего запроса, так что они не могут быть оценены на строку внешнего запроса.

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

Исключительная ситуация происходит для случая, где подзапрос IN может быть переписан как объединение SELECT DISTINCT. Пример:

SELECT col FROM t1 WHERE id_col IN (SELECT id_col2 FROM t2 WHERE

condition);

Эта инструкция может быть переписана следующим образом:

SELECT DISTINCT col FROM t1, t2 WHERE t1.id_col = t2.id_col AND

condition;

Но в этом случае объединение требует операции DISTINCT, и не более эффективно, чем подзапрос.

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

SELECT a FROM outer_table AS ot

WHERE a IN (SELECT a FROM inner_table AS

it WHERE ot.b = it.b);

Для этого запроса MySQL всегда просматривает сначала outer_table, а затем выполняет подзапрос на inner_table для каждой строки. Если outer_table имеет много строк, и inner_table имеет немного строк, запрос, вероятно, не будет работать с такой скоростью как могло бы быть.

Предшествующий запрос мог бы быть переписан подобно этому:

SELECT a FROM outer_table AS ot, inner_table AS it

WHERE ot.a = it.a AND

ot.b = it.b;

В этом случае мы можем просматривать маленькую таблицу (inner_table) и искать строки в outer_table, что будет быстро, если имеется индекс на (ot.a,ot.b).