MySQL 5.7及更早版本中UPDATE子查询直接引用目标表必报ERROR 1093，因执行器禁止同一语句对表既读快照又写更新以保障一致性；绕过需用带别名的派生表JOIN或临时表，且必须确保一对一匹配、关联字段有索引、外层WHERE不可省。
MySQL 5.7 及更早版本中，UPDATE 语句里直接用子查询引用目标表会报错，这不是你写错了，而是引擎强制限制；MySQL 8.0+ 虽支持部分自引用语法，但仍有隐含陷阱，不能无脑照搬。
为什么 UPDATE t SET x = (SELECT ... FROM t) 一定报错
错误信息是：You can't specify target table 't' for update in FROM clause。这不是语法校验失败，而是 MySQL 查询执行器在打开表时做了保护：它不允许同一个语句中对同一张表既做“读快照”又做“行更新”，否则可能读到中间态数据、破坏一致性，甚至引发死锁。即使子查询加了 WHERE 条件、哪怕只查一行，也拦不住这个报错。
用 JOIN 包一层派生表是最稳的写法
把子查询结果当“临时表”参与 JOIN，MySQL 就不再认为你在操作原表本身。关键点不是“套括号”，而是必须有别名 + 显式关联条件：
UPDATE users u JOIN (SELECT id, email FROM users WHERE status = 'pending') AS src ON u.id = src.id SET u.status = 'processed';- 子查询里不能出现
FROM users的裸写法，必须包装成(SELECT ...) AS alias - 外层
UPDATE的WHERE条件不能省——它控制实际更新哪些行，否则可能全表误改 - 如果关联字段没索引，JOIN 会变慢，建议先
EXPLAIN看执行计划
用临时表适合复杂逻辑或多次复用子查询结果
当子查询很重（比如含 GROUP BY、窗口函数、多层嵌套），或者你要在 UPDATE 里反复引用同一份中间结果时，建临时表比反复包装派生表更清晰、性能也更可控：
CREATE TEMPORARY TABLE tmp_max_sal AS SELECT dept_id, MAX(salary) AS max_sal FROM employees GROUP BY dept_id;UPDATE employees e JOIN tmp_max_sal t ON e.dept_id = t.dept_id SET e.flag = 'top' WHERE e.salary = t.max_sal;- 临时表只在当前会话可见，断开即销毁，不用手动
DROP（但显式DROP TEMPORARY TABLE更稳妥） - 注意临时表字段类型要和目标表匹配，否则隐式转换可能拖慢 JOIN 或导致意外 NULL
MySQL 8.0+ 的 CTE 写法看似简洁，但容易漏掉 WHERE 条件
虽然可以写 WITH cte AS (SELECT ...) UPDATE ... JOIN cte，但 CTE 不是银弹：
- CTE 在 MySQL 中是物化（materialized）的，意味着它会先执行完再参与 UPDATE，内存/磁盘开销比普通派生表更大
- 很多人写成
UPDATE t SET x = (SELECT y FROM cte WHERE cte.id = t.id)，结果忘了给外层加WHERE id IN (SELECT id FROM cte)，导致非匹配行被设为 NULL - CTE 无法用索引加速 JOIN，而派生表若含合适
WHERE条件，优化器可能下推过滤
真正容易被忽略的是：无论用哪种绕过方式，都得确认子查询返回结果与目标行是一对一关系。如果子查询对某行返回多行或 NULL，UPDATE 行为就不可控——要么报错，要么静默设为 NULL，而这种问题在线上往往第二天才暴露。
