MySQL存储过程中用UPDATE JOIN批量更新最简洁高效，语法为UPDATE表名JOIN关联表ON条件SET目标字段=值，禁止套用SELECT写法或使用FROM子句，须先用SELECT验证匹配结果并加事务与异常处理。
存储过程里用 UPDATE ... JOIN 实现多表批量更新
MySQL 5.7+ 和 MariaDB 支持 UPDATE 语句直接 JOIN 多张表，这是最简洁、性能也最好的方式。别写循环或临时表——除非业务逻辑真需要逐行判断。
常见错误是把 SELECT 的写法套过来，比如写成 UPDATE t1 SET t1.col = t2.val FROM t1 JOIN t2 ON ...，这在 MySQL 里会报错：ERROR 1064 (42000): You have an error in your SQL syntax。
- 正确写法是把
JOIN放在UPDATE关键字之后，且不能带FROM - 被更新的表名必须明确出现在
UPDATE后（如UPDATE orders），不能只写别名 - 关联条件要足够精确，否则可能误更新大量数据；建议先用
SELECT验证匹配结果
UPDATE orders o
JOIN customers c ON o.customer_id = c.id
JOIN order_items oi ON o.id = oi.order_id
SET o.status = 'shipped',
o.updated_at = NOW()
WHERE c.country = 'CN' AND oi.product_code LIKE 'A%';
SQL Server 中用 MERGE 替代 UPDATE + JOIN
SQL Server 不支持 UPDATE ... JOIN 语法，硬写会报错：Incorrect syntax near the keyword 'JOIN'。必须用 MERGE，它本质是“upsert”，但可只做 UPDATE 分支。
容易踩的坑是忽略 WHEN MATCHED 的触发条件——哪怕只写 UPDATE，也必须有 ON 子句定义匹配逻辑，且目标表只能是 MERGE 的 INTO 表。
-
MERGE必须以分号结尾，少写会报错：Incorrect syntax near 'MERGE' - 不能在
UPDATE子句里引用源表（USING）的字段时漏掉别名，比如写SET t.status = s.new_status，而不是SET status = new_status - 如果只更新不插入，记得加
WHEN NOT MATCHED BY TARGET THEN INSERT ...或干脆不写该分支，但语法上必须有WHEN MATCHED
MERGE orders AS t
USING (
SELECT o.id, c.country, MAX(oi.created_at) as last_item_time
FROM orders o
JOIN customers c ON o.customer_id = c.id
JOIN order_items oi ON o.id = oi.order_id
GROUP BY o.id, c.country
) AS s ON t.id = s.id
WHEN MATCHED AND s.country = 'US' THEN
UPDATE SET t.priority = 1, t.updated_at = GETDATE();
PostgreSQL 用 FROM 子句实现多表更新
PostgreSQL 的写法最接近直觉：UPDATE ... FROM ... WHERE。但它和 MySQL 的 JOIN 不同，FROM 是额外的来源表，不是主表的连接方式——主表仍只能有一个。
典型错误是以为能像 SELECT 那样链式 JOIN，结果发现 WHERE 条件里引用不到第三张表字段，或者更新行为不符合预期（比如重复匹配导致一行被多次更新）。
-
FROM后可以跟子查询或表，但必须用别名，且所有WHERE条件中的字段都要带明确别名 - 如果
FROM的结果存在一对多关系，PostgreSQL 会任选一条匹配记录更新，不会报错也不会警告 - 务必加
WHERE过滤，否则可能全表更新；建议先执行对应SELECT查看影响行数
UPDATE orders
SET status = 'processed',
updated_at = NOW()
FROM customers c, order_items oi
WHERE orders.customer_id = c.id
AND orders.id = oi.order_id
AND c.region = 'EU'
AND oi.quantity > 5;
事务与错误处理不能省略
批量更新一旦出错，没事务包裹就可能留下脏数据。尤其跨表更新时，中间某张表失败而其他已提交，后续很难回滚。
很多人只在存储过程开头写 BEGIN TRANSACTION，却忘了加 TRY...CATCH（SQL Server）或 EXCEPTION（PostgreSQL），导致错误发生后事务没回滚，还继续往下执行。
- MySQL 存储过程中要用
DECLARE EXIT HANDLER FOR SQLEXCEPTION捕获异常并ROLLBACK - SQL Server 的
@@ERROR在每条语句后都会重置，不能只在最后查一次 - PostgreSQL 的
RAISE EXCEPTION要配合EXCEPTION块，否则错误会直接中断整个过程
复杂点在于：不同数据库对“部分成功”的容忍度不同，而业务往往要求“全成功或全失败”。别依赖应用层补偿，存储过程里就得把边界守死。