MySQL支持UPDATE JOIN语法，其他主流数据库如PostgreSQL、SQL Server、SQLite均不支持，须改用各自语法（如UPDATE FROM）；必须明确目标表、加WHERE防误更新、建索引优化性能，并用事务与ROW_COUNT()校验。
UPDATE ... JOIN 语法必须用 MySQL 或 MariaDB
PostgreSQL、SQL Server、SQLite 都不支持 UPDATE ... JOIN 这种写法，硬套会直接报错 ERROR: syntax error at or near "join"。MySQL 是少数原生支持该语法的主流数据库，且从 5.7 到 8.0 行为一致。如果你用的是 PostgreSQL，得改用 UPDATE ... FROM；SQL Server 要用 UPDATE ... FROM ... INNER JOIN（注意语法位置和别名限制）。
WHERE 条件漏掉 ON 后的主键/唯一键约束
常见错误是只写业务字段匹配，比如 ON a.order_id = b.order_id AND a.status = 'pending'，但没确保 a.order_id 在表 a 中是主键或有唯一索引。结果可能触发“多对一”更新——一条 b 记录被多条 a 记录匹配，最终只有最后一条生效，数据被静默覆盖。
- 务必在
ON子句中使用能保证左表单行匹配的字段组合，例如ON a.id = b.a_id（a.id是主键） - 执行前先用
SELECT验证交集数量：SELECT COUNT(*) FROM table_a a JOIN table_b b ON a.id = b.a_id WHERE b.status = 'ready';
- 如果业务逻辑依赖复合条件（如时间+用户ID），记得给这些字段建联合索引，否则 JOIN 可能全表扫描
SET 字段写错表别名或用了子查询导致性能崩掉
容易把 SET b.status = 'done' 写成 SET a.status = 'done'（更新了源表而非目标表），或者在 SET 里塞 (SELECT ...) —— MySQL 会为每一行重新执行子查询，10 万行就查 10 万次。
- 明确谁是被更新的目标表：在
UPDATE table_b b JOIN table_a a ...中，table_b是目标，所有SET字段必须属于b - 避免在
SET中调用函数或子查询；如需计算，提前用临时表或 CTE 拆出来 - 加
LIMIT测试（仅 MySQL）：UPDATE table_b b JOIN table_a a ON b.id = a.b_id SET b.synced = 1 LIMIT 10;，确认逻辑无误再删
没有事务包裹 + 缺少影响行数校验
线上环境直接跑跨表 UPDATE，一旦出错没法回滚，而且你根本不知道到底改了几行。MySQL 的 ROW_COUNT() 返回值常被忽略，但它是唯一能告诉你“是否真的更新了预期数据”的依据。
- 必须用
BEGIN; ... UPDATE ...; SELECT ROW_COUNT(); COMMIT;包裹 - 如果预期更新 500 行，但
ROW_COUNT()返回 0，说明 JOIN 条件没命中任何记录——可能是时间范围错、状态值大小写不一致（'Ready'≠'ready'）、或字符集排序规则差异 - 别依赖客户端返回的“Query OK, X rows affected”，它可能被连接池或驱动截断；显式查
ROW_COUNT()才可靠
实际操作中最容易卡住的，是以为 JOIN 条件写对了，结果因为没建索引导致语句卡死几分钟，或者 WHERE 里用了函数让索引失效。上线前一定在测试库用 EXPLAIN FORMAT=TREE 看执行计划。
