Такой Апдейт:

UPDATE e
INNER JOIN src
using (`email`)
INNER JOIN al
on UPPER(src.`title`) = UPPER(al.`alias`)
SET e.`title_id` = al.`title_id`
WHERE e.title_id = 0 AND e.source_id = 0

Такой Селект, полностью аналогичный:

SELECT * FROM e
INNER JOIN src
using (`email`)
INNER JOIN al
on UPPER(src.`title`) = UPPER(al.`alias`)
WHERE e.title_id = 0 AND e.source_id = 0

В результате SELECT выполняется за несколько секунд, нашел 0 (ноль) записей, а UPDATE работал больше двух часов, но так и не закончил.

В чем причина? Как оптимизировать?

Например индексы перестраиваются

потому, что запрос полный ПЭ.

у тебя e никак не связана с al  и с src

нафига там иннер впёрся - неясно. Я бы тоже на месте sql сервера задумался, че ты хочешь вот ю вонт ?

(1) Какие индексы, где перестраиваются?
(2) Конечно, КО! Иначе бы он не тормозил и этой темы бы не существовало.

(3) связан же. Посмотри еще раз:
e INNER JOIN src using (`email`)

(6) ааа.. дурацкий синтаксис mysql

у тя title_id и source_id  - числовые поля ?

(8) Да

вообще, нажми на я в верхнем углу. Там есть похожие запросы.
ХЗ, mysql не особо юзал

(10) в Я всякая хрень, смотрел уже.

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

Вот такой эксперимент работает как и положено, не долго:

UPDATE e
INNER JOIN
(SELECT e.id, al.`title_id`
FROM e
INNER JOIN src
using (`email`)
INNER JOIN al
on UPPER(src.`title`) = UPPER(al.`alias`)
WHERE e.title_id = 0 AND e.source_id = 0) t1
using (`id`)
SET e.`title_id` = t1.`title_id`

(11) ну не знаю, что ты там смотрел, первые же ссылки говорят, что инсерт и апдейт  вmysql зло и куча веток по оптимизации и настроек самого mysql

(13) Там абсолютно другие случаи. У меня на сервере ни апдейты, ни селекты не тормозят.
Тормозит только один конкретный запрос.

триггеры?

скорее всего мимо , но в tsql - функции (UPPER, LEN,  и др и пр) - убивают поиск по индексу.

Да это все очевидные факты, но к решению проблемы не имеют никакого отношения.

а в mysql есть помещение во временную таблицу?

(18) Конечно

а нельзя поместить в ВТ результат по Селект, а потом сделать update по данным из ВТ? Будет чудо или нет?

(20) Можно конечно, апдейт будет быстрее работать.

Как это поможет узнать в чем причина ситуации, описанной в (0)

(21) у тебя было 2 вопроса "В чем причина? Как оптимизировать?", я на 2ой искал путь )
а на 1ый, чтобы ответить, надо план запроса как минимум посмотреть

id    select_type    table    type    possible_keys    key    key_len    ref    rows    Extra
1    SIMPLE    al    ALL    NULL    NULL    NULL    NULL    5171    
1    SIMPLE    e    index_merge    email,source_id,title_id    source_id,title_id    4,4    NULL    16440    Using intersect(source_id,title_id); Using where
1    SIMPLE    src    eq_ref    PRIMARY    PRIMARY    452    app_system.e.email    1    Using where

+(23)
Это был UPDATE

Для СЕЛЕКТА все то же самое, кроме последней колонки EXTRA, вторая строка:
Using intersect(source_id,title_id); Using where; Using join buffer (flat, BNL join)

(22) Я хотел узнать способ не как сделать другой запрос, с вложенными, а может есть способ в этом запросе что-то минимально изменить или добавить какую-нибудь дерективу, чтобы он работал так же как СЕЛЕКТ.

Можно конечно, в сторону хинтов посмотреть. force order там типа. не знаю, что есть в мускуле