А вот тоже поинтересуюсь .. (а то гложет меня сомнение)

Скажем есть такой запрос:



То есть имеем подзапрос в IN() который легко разворачивается в JOIN и соответственно, всё оптимизатором предварительно преобразуется примрно к этому:



И по сути, оптимизировать такой запрос по скорости - только играться с перестановкой условий с учетом наличных индексов, в т.ч. составных (они там есть в достатке, подойдет много разных вариантов)

Или я это не верно представляю себе? Сервер Перкона последняя, движок соответственно xtraDB
Ну и ещё: выходной поле t1.f1 - в запросе фигуряет с условием константного типа .. можно же гарантировано вместо него выдавать эту константу .. ну или вообще опустит для экономии трафика .. :)
---------
Историки часто находят артефакты древней высокоразвитой Цивилизации со странными буквами - СССР

miksoft,

Ну вот сидит в башке, где-то читал что планировщик запроса сначала его преобразует к базовому соединению, перемещая все условия в джойнах в часть "где,куда(почем)" .. в данном случае в IN() конкретно запрос, не зависящий от охватывающей части.
А вот может ли мускуль преобразовать IN() .. помнится 2011-12 ещё нет, но с тех пор, насколько помню над этим плотно работали, и несколько раз писалось за "улучшения" ..

вот и интересно, "до чего уже техника дошла"? :)

P.S. Explain на первый выдает 3 таблицы уровня ref и eq_ref, и никакой "промежуточной" не создает. Индексы пользует так, как будто бы он развернул IN() .. вот, поэтому и гложет сомнение .. уточнить бы.

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