Все здравствуйте!

Есть батарея вложенных запросов типа


Все поля соответствующие поля проиндексированЫ.
Но в плане пишется (и собственно сам запрос выполняется медленно), что самый внешний запрос не индексирован, в отличии от всех подзапросов.
Пишет, что внешней таблицы возможные и используемые ключи НУЛЛ, и говорит, что используется (понимаю для сканирования) where.
Когда у вложенных там пишутся первичные ключи и говорит, что используется индекс
И, что интересно, если исполнять самостоятельно фрагменты подзапросов  (на любой стадии вложенности), то для них сохраняется та же тенденция: внешний (и только внешний) запрос не индексируется!
Не помогает также и явное указание к использованию соответствующего индекса use undex (my_index)!

Почему так происходит?
Что делать?

Спасибо!!!

прошу прощения.
c using where ситуация чуть другая...;

в общем

вот количество строк в результирующей выборке, к примеру 4963, тогда как в rows, обработанных для table1, показывает 1951194.
И еще что странно, что для остальных таблиц rows = 1. Тогда как действительно средние два подзапроса возвращают явно многострочные наборы данных.
??????????
Но, все же, главный вопрос, почему внешний запрос не использует индексы?

Странно!
Если исходный запрос обернуть дополнительно следующим образом



то пишет, что ключ и индекс используются 

НО!!!!!!
1) запрос выполняется еще медленнее и обрабатываемое количество записей все равно остается 1951194 (и, что тоже странно, <> общему количеству строк в table1 1969719)
2)  не понятна логика, ведь оба указанных поля одинаково проиндексированы. С той только разницей, что id - первичный ключ.

жду Вашего совета!!!
Спасибо!!!

Это сообщение отредактировал(а) setnull - 22.2.2010, 02:39

какой-то стремный запрос. почему бы не использовать join?

Контекст:
 InnoDB базы быстро и беспорядочно разростаются - отказываемся от InnoDB, теряем возможность использовать внешние ключи
 Хостер не дает использовать триггеры
Для поддержания целостности БД, удаления записей производятся процедурами, получающими на входе условие, фильтрующее удаляемые из текущей таблицы записи (к примеру 
). Процедуры исполняют подготавливаемый запрос на удаление 
, предварительно вызывая соответствующие процедуры удаления зависимых (дочерних по "внешнему отношению") таблиц с условиями 
.
1) Буду очнь признателен, если кто поможет в решении именно этой задачи (отдельное спасибо за перестройку представленной мной конструкции в конструкцию с объединениями  ) но при этом:
2) Даже если эту всю логику запихнуть в соединения и т.д., то в любом случае в итоге мы придем опять-таки к тому же 
, т.к. не очень мне нравится вручную построчно удалять из таблицы по списку id  из курсора

Т.к. если логика удаления чуть сложнее, чем 

и завязана на данных из других таблиц, то без where filed in (select) никак не обойтись(или в МэйСКЛ есть что-то подобное удалениям из соединений МССКЛ?), а он все так же не использует индексы!!!!!!!!!! И больше того, в подзапросе такого delete не допускается использование исходной таблицы, из которой производится удаление )))))))))))
3) Я конечно буду очень рад, если здесь мне помогут с моей практической задачей, но все же, в любом случае, структура where in (select), как никак, часть стандарта? Ее применение не ограничивается исключительно данной здачей. И мой целевой вопрос был ориентирован на то, чтоб узнать, почему она работает именно так, и чтоб разобраться, как корректно ее использовать с расчетом на эффективное выполнение.
Спасибо!!!

Добавлено через 5 минут и 55 секунд

Приведите конкретную задачу где без нее не обойтись. А вообще вложенных подзапросов стоит избегать.

Благодарю!!!!!!!!
столкнусь - обязательно напишу   

Более того!!!!!!!!
можно


Это сообщение отредактировал(а) setnull - 23.2.2010, 12:47

вот хороший пример.
Он надуманный (точнее выдуманный), но отражает нюанс
Есть 
Собственники
Сети магазинов
Магазины

Нужно выбрать Собственников по критерию определяемому магазином (пусть по географическому расположению).
Так можно либо сделать запрос Собственников where exists(соотв магазины), либо поприсоединять все и сгруппировать по полям Собственника интересующей информации.

А если еще и нужно навыбирать информацию о Собственнике, не касающуюся деятельности магазинов (Историю местопроживания в период превышения индекса махинацийи в туристическом бизнесе определенного порога и Движение денежных счетов, открытых в вылюте, показавшей максимальный тренд за прошлый месяц), то, думаю, вообще как тут соединять все в одну яму, множить строки громадных выборок комбинациями, а потом там пытаться что-то выгрести и проанализировать?
Вот если даже и заставить себя написать такой запрос с соединениями (и такое получится), то как у сервера получится справится с ним эффективнее чем с подзапросами, если он даже не пользуется индексами при элементарном where  in (select)?

а еще
вот это тоже считается подзапросом и тоже не стоит использовать?

в данной форме - как cross join четырем таблиц - его использовать невозможно. точнее, не могу представить ситуации, когда без декартового произведения четырех таблиц нельзя было бы обойтись.
может, вместо придумывания синтетичиских ситуаций, в которых "можно было бы использовать подзапрос"(если тебе так хочется, используй подзапросы везде; запретить тебе никто не может), привел бы реальную задачу, в которой ты не можешь представить, как использовать join?