MySQL 5.7及更早版本禁止UPDATE中直接引用目标表，需用JOIN或派生表绕过；MySQL 8.0+和PostgreSQL支持子查询或FROM语法自引用更新，但需注意匹配精度、索引优化与事务安全。
UPDATE 中直接引用自身表会报错
MySQL 8.0+ 和 PostgreSQL 允许在 UPDATE 中用子查询引用本表，但 MySQL 5.7 及更早版本会报错 ERROR 1093 (HY000): You can't specify target table 't' for update in FROM clause。这不是语法写错了，是引擎限制——它禁止在 UPDATE t SET ... WHERE x IN (SELECT ... FROM t) 这类结构中把 t 同时当目标和源。
绕过方法不是“加个中间层”就行，得看实际需求选路径：
- 若只需按同表某字段聚合结果更新（如“把每个部门薪资最低员工的 status 设为 'low'”），优先用
JOIN+ 聚合子查询包装一层 - 若逻辑依赖多行比较（如“把 salary 高于本部门平均值的员工标记为 'above_avg'”），必须用派生表或 CTE 隔离读取上下文
- PostgreSQL 用户可直接用
UPDATE ... FROM语法，无需额外包装
MySQL 中用 JOIN 模拟自引用更新
核心思路：把子查询结果作为临时“另一张表”，再和原表 JOIN。关键在于子查询必须有明确别名，且不能直接写 FROM t，要套一层 (SELECT ...) AS alias。
例如，将每个部门中 salary 最高的员工 flag 设为 1：
UPDATE employees AS e JOIN ( SELECT dept_id, MAX(salary) AS max_sal FROM employees GROUP BY dept_id ) AS m ON e.dept_id = m.dept_id AND e.salary = m.max_sal SET e.flag = 1;
注意点：
-
JOIN条件里必须包含能唯一匹配行的组合（这里用了dept_id + salary，若同部门有多人并列最高，都会被更新） - 子查询里不能出现
e.*或任何对外部表的引用——它必须是独立可执行的 - 如果原表有主键，
JOIN时用主键比用业务字段更安全（避免误匹配）
PostgreSQL 的 UPDATE FROM 更直观
PostgreSQL 支持 UPDATE ... FROM 语法，允许直接把本表当作 FROM 子句中的“其他表”来用，只要别名不同即可：
UPDATE employees e1 SET flag = 1 FROM employees e2 WHERE e1.dept_id = e2.dept_id AND e1.salary = (SELECT MAX(e3.salary) FROM employees e3 WHERE e3.dept_id = e2.dept_id);
或者更高效地用聚合子查询做 FROM：
UPDATE employees e1 SET flag = 1 FROM ( SELECT dept_id, MAX(salary) AS max_sal FROM employees GROUP BY dept_id ) e2 WHERE e1.dept_id = e2.dept_id AND e1.salary = e2.max_sal;
区别在于：
- MySQL 的
JOIN方式要求匹配条件完全覆盖更新意图，否则可能漏行或多行 - PostgreSQL 的
FROM允许更灵活的关联逻辑，但要注意子查询返回多行时是否触发笛卡尔积 - 两者都需警惕 NULL 值参与比较（
salary = NULL永远不成立）
容易忽略的事务与性能陷阱
这类操作常被当成“单条 SQL”执行，但实际可能隐含全表扫描或锁升级：
- 子查询若没走索引（比如
GROUP BY dept_id但dept_id无索引），UPDATE 会变慢且长时间持有行锁 - 在高并发场景下，用
JOIN更新可能引发死锁——特别是多个会话同时更新同一部门数据时 - MySQL 中若子查询返回空结果，整个
UPDATE影响行为 0 行，不会报错，容易误判执行成功 - 测试时务必用
SELECT先验证子查询结果，再套进UPDATE，别跳步
真正麻烦的不是语法，是搞清“我到底想基于哪些行的状态去改当前行”——逻辑错，再对的 SQL 也救不回来。
