Cập nhật: Câu trả lời này bao gồm phân loại lỗi chung. Để có câu trả lời cụ thể hơn về cách xử lý tốt nhất truy vấn chính xác của OP, vui lòng xem các câu trả lời khác cho câu hỏi này
Trong MySQL, bạn không thể sửa đổi cùng bảng mà bạn sử dụng trong phần CHỌN.
Hành vi này được ghi lại tại:
http://dev.mysql.com/doc/refman/5.6/en/update.html
Có lẽ bạn chỉ có thể tham gia bảng để chính nó
Nếu logic đủ đơn giản để định hình lại truy vấn, mất truy vấn con và tham gia bảng vào chính nó, sử dụng các tiêu chí lựa chọn phù hợp. Điều này sẽ khiến MySQL xem bảng là hai thứ khác nhau, cho phép các thay đổi mang tính hủy diệt đi trước.
UPDATE tbl AS a
INNER JOIN tbl AS b ON ....
SET a.col = b.col
Ngoài ra, hãy thử lồng các truy vấn con sâu hơn vào một mệnh đề từ ...
Nếu bạn thực sự cần truy vấn con, có một cách giải quyết, nhưng nó xấu vì nhiều lý do, bao gồm hiệu suất:
UPDATE tbl SET col = (
SELECT ... FROM (SELECT.... FROM) AS x);
Truy vấn con lồng nhau trong mệnh đề TỪ tạo ra một bảng tạm thời ẩn , do đó, nó không được tính là cùng một bảng bạn đang cập nhật.
... nhưng coi chừng trình tối ưu hóa truy vấn
Tuy nhiên, hãy cẩn thận rằng từ MySQL 5.7.6 trở đi, trình tối ưu hóa có thể tối ưu hóa truy vấn con và vẫn gây ra lỗi cho bạn. May mắn thay, optimizer_switch
biến có thể được sử dụng để tắt hành vi này; mặc dù tôi không thể khuyên bạn nên làm điều này như bất cứ điều gì hơn là một sửa chữa ngắn hạn, hoặc cho các nhiệm vụ một lần nhỏ.
SET optimizer_switch = 'derived_merge=off';
Cảm ơn Peter V. Mørch cho lời khuyên này trong các ý kiến.
Kỹ thuật ví dụ là từ Baron Schwartz, ban đầu được xuất bản tại Nabble , được diễn giải và mở rộng ở đây.