postgresql中update的from子句禁止直接引用目标表，否则会被静默忽略导致误更新；必须用带别名的子查询封装源数据，并显式写出等值关联条件，避免笛卡尔积或多对一不确定性。
PostgreSQL 中 UPDATE 语句里**不能在子查询的 FROM 子句中直接写目标表本身**，不是语法写错了，而是引擎主动拒绝——它会静默忽略整个 FROM 部分，导致你以为关联更新成功，实际却更新了全表或根本没按预期改。
PostgreSQL 的 UPDATE FROM 不允许目标表出现在 FROM 中
比如你写：
UPDATE users u SET email = src.email FROM users src -- ❌ 错误：目标表 users 同时出现在 UPDATE 和 FROM 中 WHERE u.id = src.id;
这条语句不会报错，但 FROM users src 被完全跳过，WHERE 条件失效，email 会被设成 src.email 的默认值（通常是 NULL 或第一行值），返回 “UPDATE 1000” 却毫无意义。
原因在于 PostgreSQL 的解析阶段就禁止这种自引用歧义：目标表只能在 UPDATE 关键字后声明一次，FROM 必须是“其他表”或封装好的子查询。
- 目标表别名（如
u）只在UPDATE和SET中有效，不能在FROM里再出现 - 想用本表数据更新本表？必须通过子查询包装，且起新别名，例如
(SELECT id, email FROM users) AS src - 即使加了
AS别名，只要底层是同一张物理表且没做隔离，仍可能被识别为自引用而忽略
为什么显式关联条件 t.id = src.id 不可省略
漏掉等值连接条件，FROM 子句会退化为笛卡尔积。比如：
UPDATE users u SET status = 'active' FROM new_contacts src WHERE src.is_valid; -- ❌ 缺少 u.id = src.user_id
只要 new_contacts 有 100 行，users 就会被更新 100 次 × 行数，最终每行都变成 src 中某一行的 status 值（取决于执行顺序）。
-
WHERE里只写src.xxx = 'val'是过滤源表，不是建立关联 - 必须至少有一个
t.col = src.col形式的等值条件，且字段类型兼容、无隐式转换风险 - 如果关联字段含
NULL，等值判断失败，对应行不会被更新——这不是 bug，是 SQL 三值逻辑的正常表现
多对一场景下不加 DISTINCT ON 或聚合会出事
当一个目标表主键（如 users.id）在源结构中匹配到多行（如用户有多个有效联系方式），PostgreSQL 默认取任意一行（无序），结果不可控：
UPDATE users u SET phone = src.phone FROM contacts src WHERE u.id = src.user_id AND src.is_primary = false; -- 可能有多个非主联系方式
哪怕只有一行被选中，你也无法预测是哪条；更糟的是，不同执行计划可能选出不同行。
- 用
DISTINCT ON (u.id)显式指定优先级：(SELECT DISTINCT ON (user_id) user_id, phone FROM contacts ORDER BY user_id, is_primary DESC) - 或改用聚合：
MAX(phone)/STRING_AGG(...)，前提是业务允许 - 验证手段仍是把
FROM + WHERE拆成SELECT，检查是否有重复u.id
子查询必须带别名，且字段冲突要显式限定
以下写法会直接报错 missing FROM-clause entry：
UPDATE users u SET email = src.email FROM (SELECT id, email FROM contacts) -- ❌ 缺少 AS 别名 WHERE u.id = src.id;
而如果子查询和目标表都有 id 字段，又没限定，解析器无法分辨 src.id 指谁：
FROM (SELECT id, email FROM users) AS src -- ✅ 有别名 WHERE u.id = src.id; -- ✅ 显式用别名限定
- 子查询别名是强制要求，不是可选项
- 字段名冲突时，
src.id和u.id必须都带别名，否则报column reference "id" is ambiguous - 嵌套太深（三层以上子查询）会让执行计划变差，优先考虑
WITH提前定义
最危险的不是语法报错，而是看似执行成功却更新错数据——每次写 UPDATE FROM 前，先把它转成 SELECT 跑一遍，确认行数、去重性和字段来源，比加事务还管用。
