Atualização:Esta resposta abrange a classificação geral de erros. Para obter uma resposta mais específica sobre como lidar melhor com a consulta exata do OP, consulte outras respostas a esta pergunta
No MySQL, você não pode modificar a mesma tabela que você usa na parte SELECT.
Este comportamento está documentado em:http://dev.mysql.com/doc/refman/5.6/en/update.html
Talvez você possa simplesmente unir a tabela a ela mesma
Se a lógica for simples o suficiente para remodelar a consulta, perca a subconsulta e una a tabela a ela mesma, empregando critérios de seleção apropriados. Isso fará com que o MySQL veja a tabela como duas coisas diferentes, permitindo que mudanças destrutivas continuem.
UPDATE tbl AS a
INNER JOIN tbl AS b ON ....
SET a.col = b.col
Como alternativa, tente aninhar a subconsulta mais profundamente em uma cláusula from ...
Se você realmente precisar da subconsulta, há uma solução alternativa, mas é ruim por vários motivos, incluindo desempenho:
UPDATE tbl SET col = (
SELECT ... FROM (SELECT.... FROM) AS x);
A subconsulta aninhada na cláusula FROM cria uma tabela temporária implícita , portanto, não conta como a mesma tabela que você está atualizando.
... mas cuidado com o otimizador de consultas
No entanto, cuidado com o MySQL 5.7 .6 e em diante, o otimizador pode otimizar a subconsulta e ainda fornecer o erro. Felizmente, o
optimizer_switch variável pode ser usada para desligar este comportamento; embora eu não pudesse recomendar fazer isso como algo mais do que uma correção de curto prazo ou para pequenas tarefas pontuais. SET optimizer_switch = 'derived_merge=off';
Agradecimentos a Peter V. Mørch para este conselho nos comentários.
A técnica de exemplo foi do Barão Schwartz, publicado originalmente em Nabble , parafraseado e estendido aqui.
