Ошибка ссылки на основную таблицу в подзапросе поиска для обновления

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

Несмотря на то, что связанные с вами обходные пути выглядят так, будто они просто добавляют слой select вокруг исходного подзапроса, например. select * from (your original subquery), вы упустили причину, по которой они работают: они используют производную таблицу вместо (зависимого) подзапроса (именно это имел в виду @Cheekysoft с неявной временной таблицей в вашем связанный ответ). Производная таблица не может зависеть от внешнего запроса (поэтому основная проблема исчезла). Он более или менее обрабатывается как любая реальная таблица (обратите внимание, например, что вы должны назвать производную таблицу, в вашем случае aa; см., например, еще один мой ответ для более подробной информации об этом).

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

Таким образом, основная стратегия состоит в том, чтобы поместить все строки, которые вам когда-либо понадобятся, в вашу производную таблицу, а затем выполнить join, чтобы выбрать строку, которая вам нужна для обновления фактической строки:

update fact_training_event_tbl
join ( your original select that returns 3 rows ) base
on base.gkey = fact_training_event_tbl.gkey
set course_date = base.course_date

«Внутри» производной таблицы (base) вы можете делать все, что хотите, и использовать fact_training_event_tbl так часто, как хотите, но зависимость от внешней fact_training_event_tbl выполняется «снаружи» base с помощью on- условие.

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

update fact_training_event_tbl
join fact_training_event_tbl base
on base.gkey = fact_training_event_tbl.gkey + 1
set course_date = base.course_date

В вашем случае это сработало бы, если бы вы имели в виду "поле gkey, которое является последовательным первичным ключом int" буквально (то есть без пробелов). Но даже если нет, это должно проиллюстрировать аналогию между использованием обычной и производной таблиц в этой ситуации.

Сообщая об окончательном сработавшем запросе, спасибо solarflare за решение:

update fact_training_event_tbl orig
join ( SELECT aa.gkey,
    aa.course_date,
    (select course_date from BI.fact_training_event_tbl bb where bb.gkey = (
            select min(cc.gkey) from BI.fact_training_event_tbl cc where cc.gkey > aa.gkey)) as next_date
from BI.fact_training_event_tbl aa
where course_date = '1970-01-01' ) base
on base.gkey = orig.gkey
set orig.course_date = base.next_date