Update: Diese Antwort deckt die allgemeine Fehlerklassifizierung ab. Eine genauere Antwort darauf, wie die genaue Abfrage des OP am besten behandelt werden kann, finden Sie in anderen Antworten auf diese Frage
In MySQL können Sie nicht dieselbe Tabelle ändern, die Sie im SELECT-Teil verwenden.
Dieses Verhalten ist dokumentiert unter:
http://dev.mysql.com/doc/refman/5.6/en/update.html
Vielleicht können Sie den Tisch einfach mit sich selbst verbinden
Wenn die Logik einfach genug ist, um die Abfrage neu zu gestalten, verlieren Sie die Unterabfrage und verbinden Sie die Tabelle unter Verwendung geeigneter Auswahlkriterien mit sich selbst. Dies führt dazu, dass MySQL die Tabelle als zwei verschiedene Dinge betrachtet, sodass destruktive Änderungen vorgenommen werden können.
UPDATE tbl AS a
INNER JOIN tbl AS b ON ....
SET a.col = b.col
Versuchen Sie alternativ, die Unterabfrage tiefer in eine from-Klausel zu verschachteln ...
Wenn Sie die Unterabfrage unbedingt benötigen, gibt es eine Problemumgehung, die jedoch aus mehreren Gründen hässlich ist, einschließlich der Leistung:
UPDATE tbl SET col = (
SELECT ... FROM (SELECT.... FROM) AS x);
Die verschachtelte Unterabfrage in der FROM-Klausel erstellt eine implizite temporäre Tabelle , sodass sie nicht als dieselbe Tabelle zählt, die Sie aktualisieren.
... aber achten Sie auf den Abfrageoptimierer
Beachten Sie jedoch, dass der Optimierer ab MySQL 5.7.6 möglicherweise die Unterabfrage optimiert und dennoch den Fehler ausgibt. Glücklicherweise kann die optimizer_switch
Variable verwendet werden, um dieses Verhalten auszuschalten. obwohl ich nicht empfehlen kann, dies als etwas anderes als eine kurzfristige Lösung oder für kleine einmalige Aufgaben zu tun.
SET optimizer_switch = 'derived_merge=off';
Vielen Dank an Peter V. Mørch für diesen Rat in den Kommentaren.
Die Beispieltechnik stammt von Baron Schwartz, der ursprünglich bei Nabble veröffentlicht und hier umschrieben und erweitert wurde.