Actualización:esta respuesta cubre la clasificación general de errores. Para obtener una respuesta más específica sobre cómo manejar mejor la consulta exacta del OP, consulte otras respuestas a esta pregunta
En MySQL, no puede modificar la misma tabla que usa en la parte SELECT.
Este comportamiento está documentado en:http://dev.mysql.com/doc/refman/5.6/en/update.html
Tal vez puedas simplemente unir la mesa a sí misma
Si la lógica es lo suficientemente simple como para remodelar la consulta, pierda la subconsulta y una la tabla a sí misma, empleando los criterios de selección apropiados. Esto hará que MySQL vea la tabla como dos cosas diferentes, lo que permitirá que se lleven a cabo cambios destructivos.
UPDATE tbl AS a
INNER JOIN tbl AS b ON ....
SET a.col = b.col
Como alternativa, intente anidar la subconsulta más profundamente en una cláusula from...
Si necesita absolutamente la subconsulta, hay una solución, pero es desagradable por varias razones, incluido el rendimiento:
UPDATE tbl SET col = (
SELECT ... FROM (SELECT.... FROM) AS x);
La subconsulta anidada en la cláusula FROM crea una tabla temporal implícita , por lo que no cuenta como la misma tabla que está actualizando.
... pero cuidado con el optimizador de consultas
Sin embargo, tenga en cuenta que desde MySQL 5.7 .6
y en adelante, el optimizador puede optimizar la subconsulta y aún así darte el error. Afortunadamente, el optimizer_switch variable se puede utilizar para desactivar este comportamiento; aunque no podría recomendar hacer esto como algo más que una solución a corto plazo, o para pequeñas tareas únicas.
SET optimizer_switch = 'derived_merge=off';
Gracias a Peter V. Mørch por este consejo en los comentarios.
La técnica de ejemplo fue de Baron Schwartz, publicado originalmente en Nabble , parafraseado y ampliado aquí.
