mysql用update t1 join t2 on ... set t1.col=t2.col；postgresql用update t1 set col=t2.col from t2 where t1.id=t2.t1_id；sqlite和sql server另有语法；务必先select验证、加限制、建索引。
UPDATE语句里怎么写JOIN（MySQL/PostgreSQL）
标准SQL不支持UPDATE ... JOIN语法，但MySQL和PostgreSQL各自提供了扩展写法，且差异明显——别直接套用其他数据库的写法，否则报错。
- MySQL允许
UPDATE t1 JOIN t2 ON ... SET t1.col = t2.col，JOIN写在UPDATE和SET之间 - PostgreSQL必须用
FROM子句：UPDATE t1 SET col = t2.col FROM t2 WHERE t1.id = t2.t1_id - SQLite不支持关联更新，只能用子查询：
UPDATE t1 SET col = (SELECT t2.col FROM t2 WHERE t2.id = t1.t2_id) - SQL Server用
UPDATE t1 SET ... FROM t1 JOIN t2 ...，但t1必须带别名，且UPDATE后要写别名（如UPDATE a SET ... FROM t1 a JOIN t2 b ...）
WHERE条件漏写或写错导致全表误更新
关联更新最危险的不是语法，而是没加约束条件，一执行就把整张表刷成同一个值。尤其当关联字段有NULL、重复值或未建索引时，行为更难预料。
- 务必检查
JOIN或WHERE中的关联条件是否能唯一匹配目标行（比如t1.user_id = t2.id，但t2.id不是主键，就可能一对多） - 执行前先用
SELECT验证：把UPDATE换成SELECT *，确认返回的行数和数据符合预期 - 生产环境强烈建议加
LIMIT 10（MySQL）或RETURNING *（PostgreSQL）看效果，哪怕语法允许也不跳过这步
子查询方式虽然通用但性能差
当数据库不支持JOIN式更新（比如SQLite），或你不敢动复杂FROM逻辑时，子查询是 fallback 方案，但它会在每行更新时都执行一次查询，数据量一大就卡死。
- 避免在子查询里用
SELECT ... FROM t2 WHERE t2.x = t1.y ORDER BY ... LIMIT 1这类带排序+截断的写法——它无法走索引，还容易因NULL值返回空结果 - 确保子查询中
WHERE条件字段（如t2.id）在t2上有索引，否则t1每更新一行，t2就全表扫描一遍 - 如果t2数据量小（
UPDATE关联更新后没生效？查查事务和权限
语法对、条件对、也执行成功了，但数据没变——大概率不是SQL问题，而是环境限制。
- 确认当前会话是否在事务里且未
COMMIT（尤其用Python/Java等客户端时，默认autocommit关着） - 检查用户对目标表是否有
UPDATE权限，以及对被关联表是否有SELECT权限（MySQL 8.0+、PostgreSQL都校验这个） - 某些ORM（如Django ORM）不支持原生关联更新，
.update()调用会拆成多条语句，实际没走JOIN逻辑 - 触发器（Trigger）可能拦截或改写你的UPDATE，查
SHOW TRIGGERS或\d table_name确认
SELECT预览、再EXPLAIN看执行路径。
