Aktualizacja:Ta odpowiedź obejmuje ogólną klasyfikację błędów. Aby uzyskać bardziej konkretną odpowiedź na temat tego, jak najlepiej poradzić sobie z dokładnym zapytaniem OP, zobacz inne odpowiedzi na to pytanie
W MySQL nie możesz modyfikować tej samej tabeli, której używasz w części SELECT.
To zachowanie jest udokumentowane pod adresem:http://dev.mysql.com/doc/refman/5.6/en/update.html
Może możesz po prostu dołączyć do stołu
Jeśli logika jest wystarczająco prosta, aby zmienić kształt zapytania, zgubić podzapytanie i połączyć tabelę ze sobą, stosując odpowiednie kryteria wyboru. Spowoduje to, że MySQL będzie postrzegał tabelę jako dwie różne rzeczy, umożliwiając wprowadzenie destrukcyjnych zmian.
UPDATE tbl AS a
INNER JOIN tbl AS b ON ....
SET a.col = b.col
Alternatywnie spróbuj zagnieździć podzapytanie głębiej w klauzuli od ...
Jeśli absolutnie potrzebujesz podzapytania, istnieje obejście tego problemu, ale jest to z kilku powodów, w tym wydajność:
UPDATE tbl SET col = (
SELECT ... FROM (SELECT.... FROM) AS x);
Zagnieżdżone podzapytanie w klauzuli FROM tworzy niejawną tabelę tymczasową , więc nie liczy się jako ta sama tabela, którą aktualizujesz.
... ale uważaj na optymalizator zapytań
Uważaj jednak, że od MySQL 5.7 .6
i dalej, optymalizator może zoptymalizować podzapytanie i nadal wyświetla błąd. Na szczęście optimizer_switch zmienna może być użyta do wyłączenia tego zachowania; chociaż nie mogę polecić robienia tego jako czegoś więcej niż krótkoterminowej naprawy lub małych, jednorazowych zadań.
SET optimizer_switch = 'derived_merge=off';
Podziękowania dla Petera V. Mørcha za tę radę w komentarzach.
Przykładowa technika pochodzi od barona Schwartza, pierwotnie opublikowany w Nabble , sparafrazowany i rozszerzony tutaj.
