PostgreSQL UPDATE FROM 只允许一个源结构，必须用括号包裹JOIN或子查询，且WHERE中必须包含目标表与源结构的关联条件，否则将导致笛卡尔积更新；一对多关系需提前聚合去重，字段类型不一致或无索引会使ON失效。
UPDATE 语句里 FROM 多张表时，只要漏掉任一关联条件或写错连接逻辑，就会对目标表每行执行全量匹配——不是“可能出错”，而是必然更新错误行数，且无法回滚。
PostgreSQL UPDATE FROM 只允许一个源结构，别平铺三张表
PostgreSQL 的 UPDATE ... FROM 语法中，FROM 后面只能跟一个表、子查询或带别名的 JOIN 表达式，不能写成 FROM t1, t2, t3 或 FROM t1 JOIN t2 JOIN t3 平铺形式。否则会报错或隐式退化为交叉连接。
- 错误写法：
UPDATE orders SET status = 'shipped' FROM customers, addresses, shipments WHERE ... - 正确做法：把
customers和addresses先JOIN成一个虚拟表，再和shipments关联，整体作为单个源结构 - 推荐用括号明确包裹：
FROM (customers c JOIN addresses a ON c.id = a.customer_id) AS ca JOIN shipments s ON s.order_id = orders.id - 子查询方式更可控：
FROM (SELECT c.id, a.city FROM customers c JOIN addresses a ON c.id = a.customer_id) AS ca WHERE ca.id = orders.customer_id AND ca.city = 'Beijing'
WHERE 必须包含目标表与源结构的关联字段，否则就是笛卡尔积
即使 FROM 里的 JOIN 全都写对了，如果 WHERE 条件里没把目标表（比如 orders）和源结构中的某张表真正连起来，数据库会为 orders 每一行，去匹配源结构返回的全部结果——这就是隐式笛卡尔积更新。
- 危险写法：
UPDATE orders SET status = 'shipped' FROM (customers c JOIN addresses a ON c.id = a.customer_id) ca WHERE ca.city = 'Beijing'（没写ca.id = orders.customer_id） - 后果：所有订单都会被更新，只要地址表里有任意一条北京记录
- 必须补上关联：
WHERE ca.id = orders.customer_id AND ca.city = 'Beijing' - 如果源结构里没有能直接连到
orders的字段（比如只查了聚合值），就得换思路：用标量子查询或先建临时映射表
一对多关系下，JOIN 会放大行数，UPDATE 可能重复执行
当源结构中某张表是“一对多”时（例如一个用户对应多个地址），即使所有 ON 和 WHERE 都写对了，FROM 返回的中间结果仍可能比目标表行数多——导致同一条 orders 记录被多次匹配，UPDATE 会以最后匹配的值为准，但过程不可控。
- 典型场景：
customers→addresses（1:N），又 JOINshipments（1:N），最终中间结果行数 = 用户数 × 地址数 × 发货单数 - 验证方法：把
UPDATE改成SELECT COUNT(*)，看结果是否远超orders表本身行数 - 解决路径：在源结构里提前聚合或去重，例如用
DISTINCT ON (c.id)取每个用户的首个地址，或用子查询先算出customer_id → city映射 - 更稳妥的做法：避免在
FROM中引入多对一/一对多表，改用EXISTS或标量子查询判断条件
字段类型不一致或缺失索引，会让 ON 条件失效
ON 子句里看着写了关联，但如果字段类型不一致（比如 orders.customer_id 是 INTEGER，而 customers.id 是 TEXT），数据库可能无法使用索引，被迫走嵌套循环全表扫描——实际效果等同于没约束，尤其在大表上极易触发慢更新甚至锁表。
- 检查方式：用
EXPLAIN看执行计划，重点找Nested Loop节点下的Rows Removed by Join Filter是否非零，或actual rows是否异常高 - 修复优先级：先统一字段类型，其次确保外键列上有索引（
CREATE INDEX ON customers(id)） - 别在
ON里套函数：ON UPPER(c.email) = UPPER(o.email)会让索引完全失效，应提前标准化数据或加函数索引 - 如果只是需要“存在性判断”，用
EXISTS替代JOIN更安全：WHERE EXISTS (SELECT 1 FROM addresses a WHERE a.customer_id = orders.customer_id AND a.city = 'Beijing')
最常被忽略的一点是：UPDATE 的 FROM 子句里一旦用了子查询，它就固化为一次性结果集，不会随目标表更新动态变化；如果你在子查询里漏掉了 DISTINCT 或聚合，又没意识到它会被反复匹配，那更新结果基本不可信。
