MySQL禁止在UPDATE中直接引用目标表，因可能引发不一致或死锁；需用JOIN或派生表绕过，且须加WHERE条件、事务保护及抽样验证。
为什么直接在UPDATE中用子查询会报错
MySQL 不允许在 UPDATE 的 WHERE 或 SET 子句里直接引用目标表，典型错误是：You can't specify target table 'users' for update in FROM clause。这不是语法写错了，而是 MySQL 的执行机制限制：它怕你在读取和修改同一张表时产生不一致或死锁。
绕过限制的两种可靠写法
必须把子查询“包一层”变成派生表（derived table），让 MySQL 认为这是个临时结果集，而非原表本身：
- 推荐用
JOIN：语义清晰、性能通常更好，尤其当关联字段有索引时UPDATE users u JOIN (SELECT user_id, new_email FROM temp_import WHERE valid = 1) t ON u.id = t.user_id SET u.email = t.new_email; - 用派生表 + 子查询：适合单值更新场景，但注意 NULL 安全
UPDATE users SET email = (SELECT new_email FROM (SELECT user_id, new_email FROM temp_import WHERE valid = 1) AS tmp WHERE tmp.user_id = users.id) WHERE id IN (SELECT user_id FROM temp_import WHERE valid = 1);
关键点：外层 UPDATE 的 WHERE 条件不能省——它决定了哪些行参与更新，否则可能漏改或误改。
子查询更新最容易踩的三个坑
不是语法通了就安全了，这些细节决定数据对不对：
- 子查询返回多行时，
SET column = (subquery)会报错Subquery returns more than 1 row；必须确保子查询对每一行只返回一个值（加LIMIT 1或聚合函数，但要确认业务逻辑允许） - 子查询没命中任何行，结果是
NULL，可能导致字段被意外置空；加IFNULL(..., users.email)或先用SELECT验证子查询结果 - 没加事务包裹：子查询依赖的数据可能在 UPDATE 执行中途被其他事务修改；务必用
BEGIN; ...; COMMIT;包住，并检查ROW_COUNT()返回值是否符合预期
真正安全的操作流程
别跳步，线上环境必须按这个顺序走：
- 先写等效
SELECT：比如想用子查询更新邮箱，先跑SELECT u.id, u.email, t.new_email FROM users u JOIN temp_import t ON u.id = t.user_id WHERE t.valid = 1;，确认关联行数、值是否合理 - 开启安全模式：
SET SQL_SAFE_UPDATES = 1;，避免无WHERE或无索引条件的误操作 - 用事务封装：
BEGIN; UPDATE ...; SELECT ROW_COUNT(); COMMIT;；如果ROW_COUNT()为 0 或远小于预期，立刻ROLLBACK - 更新后抽样验证：比如
SELECT id, email FROM users WHERE id IN (123, 456, 789);
最常被忽略的是子查询的执行时机——它在 UPDATE 每一行时都重新执行一次，不是一次性算好再批量赋值。这意味着性能敏感场景下，JOIN 通常比相关子查询更可控。
