Есть какой-нибудь ход, не делать два селекта одной и той же строки?

Вряд ли. LIMIT 1, да и ORDER на самом деле -- это очень нереляцыонный конструкт.

Хотя, возможно, сработает что-то вроде



Но, на самом деле, это бабушка на двое сказала, что при многих вариантах совпадения выборки из mail_messages будет установлено именно последнее значение. В общем, лучшэ не рисковать.
(Да, mail_overview.id -- имеется в виду PRIMRAY KEY. Вместо него можно подставить любой другой UNIQUE, в т.ч. составной)

А Вы уверены, что оптимизатор не преобразовал этот запрос к одному? А то, можэт, и оптимизировать здесь не требуется?
  

А есть возможность это увидит?

PS. Структуру подзапроса не трогал.
PPS. Он кривой.

А какая версия? 5.1.63 не даёт в подзапросе в джойне ссылаться на другие таблицы из того жэ джойна. Unknown column, в данном случае будет unknown column `mail_overview`.`did` in where clause. Это, в общем, логично -- поскольку отношэния создаются/выбираются не по очереди в каком-то порядке, тем более не по очереди для каждой записи предыдущих отношэний выбирается следующее -- а все отношэния JOINа существуют до начала объединения. 
Сделать противоестественный интеллект, который бы определял, что для подзапросов в джойне нужны такие последовательные переборы -- наверное можно, но в общем нетривиально, и мне было бы любопытно, если бы он где-то появился.

Добавлено через 35 секунд
[quote]А есть возможность это увидит?[/quote

Поиграйтесь с explain.

tzirechnoy, да, она самая 5.1.63


Akina, кто иммено и почему?

А, да, explain UPDATE появился только в 5.6.3. Beware, как говорится.

В остальных -- можно переписать UPDATE на равнозначный SELECT.

Добавлено через 54 секунды


Да это я с Akina общался.

Не понял... ведь во внешнем запросе идёт отбор по `mail_overview`.`did`=1, во внутреннем  отсутствует группировка, следовательно, всё вырождено, подзапрос оперирует ТОЛЬКО данными таблицы mail_messages, внешний запрос - ТОЛЬКО данными таблицы mail_overview и подзапроса... Именно это в первую очередь я и имел в виду, говоря, что запрос кривой. На черезпопные условия отбора в нём можно не обращать внимания, это мелочи.

[Б]Акина[/Б], а его не надо групировать, он в overview - primary key

Прямщас вырождено. AND ((`mail_messages`.`fid`=`mail_overview`.`uid` ...

Впрочем, did как константу тожэ движок протаскивать не будет (хотя это можно было и руками сделать).
 

Развяжи ВЕСЬ запрос. Приведи подобные в диком условии подзапроса. Связывание внутреннее, и условие связывания легко выносится наружу.

А давай ты сам этим пострадаешь? Тем более, что ты вроде знаешь, как.

И вообще, версию мыскля, на которой это или что-то такое у тебя работает -- в студию. А если ни на какой не проверял, то нечего тут трындеть попусту.

Хамить совершенно необязательно. Но это к слову.

То, что написано - работать не будет, и я об этом не раз говорил. Подзапрос - кривой. Не помнишь? жаль.
На какой версии оно будет работать, если вообще когда-нибудь будет - мне по барабану. Тебе интересно? пробуй.
Если выполнить корректировку запроса, то возможно его привести к виду, когда подзапрос оперирует данными одной таблицы, а запрос - данными другой таблицы и подзапроса. Причём при полном сохранении логики. Я об этом говорил. И такой откорректированный запрос будет работать. Не знаешь как? и не надо. Задевает? мне это пофиг.

Конечно, необязательно. Но иногда -- полезно. Способствует быстрому взаимопониманию.



Значит, невнятно говорил.



Это я, конечно, помню, но к делу это не относится.



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

Топикстартеру сказано, что надо переписать запрос. И я пока не вижу попыток ТС это сделать. Зато я прекрасно помню предыдущие темы ТС и некоторые утверждения в них - посему пока ТС не начнёт реально что-то делать, я и пальцем не шевельну.


Учись отвечать только за себя. И не надо пробовать брать меня на "слабо".