mysql支持update join语法，主表须在update后首位，join顺序和on条件必须正确；postgresql用update...from替代；子查询方式兼容但性能差；关联失败可能导致null或报错，务必先select验证。
MySQL 用 UPDATE JOIN 一次改掉关联表字段
MySQL 支持 UPDATE ... JOIN 语法，能直接在更新主表时拉入关联表条件或值，不用先查再循环更新。这是最常用也最稳妥的方案，但必须写对 JOIN 顺序和 ON 条件，否则会误更新或报错。
- 主表必须出现在
UPDATE后第一个位置，JOIN 的表在它后面——UPDATE t1 JOIN t2 ON ... SET t1.field = t2.value，反了会语法错误 -
ON条件要严格匹配关联逻辑，比如用t1.user_id = t2.id而不是t1.id = t2.user_id（容易颠倒主从关系） - 如果关联结果有多行匹配，MySQL 默认只取第一行更新，不会报错，但结果不可控——务必确保
ON条件能唯一确定一条记录，或加WHERE t2.status = 'active'过滤 - 示例：
UPDATE orders o JOIN users u ON o.user_id = u.id SET o.user_name = u.name WHERE u.is_deleted = 0
PostgreSQL 没有 UPDATE JOIN，得用 FROM 子句
PostgreSQL 不支持 UPDATE ... JOIN，但可以用 UPDATE ... FROM 实现等效效果。语法不同，但逻辑一致：把关联表“放进来”，再用它的字段赋值。
-
FROM后面跟的是表名或子查询，不是 JOIN 关键字；ON 条件写在WHERE里，而不是独立子句 - 容易漏掉
WHERE中的关联约束，导致全表更新——比如忘记写u.id = o.user_id，o.user_name就会被设成同一个u.name值 - 子查询别名必须显式声明，且不能和主表同名，否则报错
table name "users" specified more than once - 示例：
UPDATE orders o SET user_name = u.name FROM users u WHERE o.user_id = u.id AND u.is_verified
UPDATE 关联子查询在所有数据库都可用，但性能差
用子查询方式（SET field = (SELECT ...)）兼容性最好，MySQL、PostgreSQL、SQL Server 都支持，但执行时每行都会触发一次子查询，数据量一大就明显变慢。
- 子查询必须返回 0 或 1 行，否则 MySQL 报错
Subquery returns more than 1 row，PostgreSQL 报more than one row returned by a subquery used as an expression - 别在子查询里漏加
LIMIT 1或WHERE限制——即使你“知道”只有一条，数据库不知道，也不优化 - 如果子查询涉及大表扫描，又没走索引，响应时间可能从毫秒级跳到秒级，线上慎用
- 示例：
UPDATE orders SET user_name = (SELECT name FROM users WHERE id = orders.user_id LIMIT 1)
WHERE 条件里混用关联字段，小心 NULL 和空结果集
无论用哪种方式，只要关联失败（比如 user_id 在 users 表不存在），对应行的更新就会失效或设为 NULL，而你可能根本没意识到。
- MySQL 默认把找不到的子查询结果转成
NULL，然后SET field = NULL—— 如果字段不允许 NULL，会报错；如果允许，数据就丢了 - PostgreSQL 更严格，子查询返回空集时直接报错，除非你显式写
COALESCE((SELECT ...), orders.user_name) - 安全做法是：先用
SELECT模拟一遍，确认UPDATE影响的行数和预期一致，比如SELECT COUNT(*) FROM orders o LEFT JOIN users u ON o.user_id = u.id WHERE u.id IS NULL - 生产环境跑前，一定加
LIMIT测试（MySQL 支持UPDATE ... LIMIT 10，PostgreSQL 需套 CTE 或子查询）
