MySQL和PostgreSQL均禁止UPDATE中直接SELECT自身表，需用JOIN、匿名表（MySQL）或CTE（PostgreSQL）绕过；多字段依赖更新推荐事务+临时表或CTE；并发下应加FOR UPDATE锁并精准控制粒度。
UPDATE 语句里不能直接用 SELECT 的结果更新自身表？
MySQL 和 PostgreSQL 都会报错，比如 ERROR 1093 (HY000): You can't specify target table 't' for update in FROM clause。这不是语法写错了，是引擎在执行时禁止对同一张表既读又写——哪怕你只是想用子查询算个值。
实操建议：
- 用
JOIN替代子查询：把要查的依赖数据当关联表，再更新主表 - 在 MySQL 中，可套一层匿名表（
SELECT ... FROM (SELECT ...) AS tmp）绕过限制 - PostgreSQL 支持
FROM子句直接跟子查询，不用嵌套
示例（MySQL 安全写法）：
UPDATE orders o JOIN ( SELECT order_id, SUM(amount) AS total FROM order_items GROUP BY order_id ) t ON o.id = t.order_id SET o.total_amount = t.total;
需要按顺序更新多个强依赖字段？用临时变量最稳
比如先算出 discount_rate，再用它算 final_price，而这两个字段都在同一张表里。直接写两个 UPDATE 不仅慢，还可能因并发导致中间状态不一致。
实操建议：
- MySQL 可用用户变量（
@var），但注意变量赋值顺序和执行计划不可控，只适合单线程或低并发场景 - 更可靠的做法是用事务 + 临时表：先把依赖计算结果存进
temp_update_table，再一次性 JOIN 更新 - PostgreSQL 推荐用
WITH（CTE）配合UPDATE ... FROM，逻辑清晰且原子性强
示例（PostgreSQL）：
WITH calc AS (
SELECT id,
COALESCE(discount_percent, 0) / 100.0 AS rate,
base_price
FROM products
)
UPDATE products p
SET final_price = p.base_price * (1 - c.rate)
FROM calc c
WHERE p.id = c.id;
分步更新时字段被其他事务改了怎么办？
典型现象：第一步 UPDATE 算出 A 字段，第二步用 A 去算 B，但中间有另一个事务改了 A，导致最终 B 错误。这不是 bug，是典型的“读-修改-写”竞态。
实操建议：
- 加
SELECT ... FOR UPDATE锁住相关行（InnoDB 支持，MyISAM 不行） - 把多步逻辑压进一个事务，且所有读操作都放在更新之前，避免重复读取
- 如果业务允许，考虑用触发器或应用层缓存中间值，而不是反复查库
关键点：锁的粒度要准。别用 SELECT * FROM t FOR UPDATE 锁全表，而是 SELECT id, a, b FROM t WHERE id IN (...) FOR UPDATE。
为什么用临时表比多次 UPDATE 更快？
不是因为“临时表本身快”，而是避免了重复扫描、重复条件判断和多次索引查找。尤其当依赖计算涉及聚合、JOIN 或函数时，每多一次 UPDATE 就多一遍全量计算路径。
实操建议：
- 临时表建在
MEMORY引擎（MySQL）或TEMPORARY表（PostgreSQL）上，不走磁盘 - 给临时表的关键字段加索引（如
CREATE INDEX ON temp_calc(order_id)），否则 JOIN 时可能变全表扫描 - 记得清理：MySQL 会自动删，PostgreSQL 需显式
DROP TABLE IF EXISTS或依赖会话生命周期
容易被忽略的是：临时表字段类型必须和目标表严格一致，否则隐式转换会导致索引失效或 JOIN 匹配失败——比如目标表 order_id 是 BIGINT，临时表建成了 INT，就可能漏匹配。
