SQL标准不支持单条UPDATE同时更新多表，MySQL的UPDATE JOIN仅更新指定主表，PostgreSQL和SQL Server的FROM/JOIN语法也仅允许修改目标表字段；安全做法是用事务分步更新或存储过程封装，并校验归档表记录存在性。
SQL 标准不支持一条 UPDATE 语句同时更新多个表，无论主表还是归档表——这是绝大多数关系型数据库（MySQL、PostgreSQL、SQL Server、Oracle）的硬性限制。试图用 UPDATE ... JOIN 同时写两个表，只会报错或被静默忽略（如 MySQL 的多表 UPDATE 实际只更新目标表，JOIN 表仅用于条件过滤）。
MySQL 中误用 UPDATE ... JOIN 的典型错误
很多人看到 MySQL 支持 UPDATE t1 JOIN t2 ON ... SET t1.col = ..., t2.col = ... 就以为能双写，但这是错觉：
-
UPDATE后面只能跟一个**目标表名**（或别名），即使写了JOIN，SET子句里给其他表字段赋值是语法错误（MySQL 8.0+ 直接报ERROR 1103: Incorrect table name） - 旧版 MySQL（5.7 及以前）允许
SET t2.col = ...写法，但实际不会执行，也不报错，极易造成数据一致性幻觉 - 即便“看似成功”，归档表字段也根本没变——必须查证，不能信返回的 “Rows matched”
PostgreSQL 和 SQL Server 完全不支持多表 UPDATE 语法
这两个系统连“看起来像能双写”的语法都没有：
- PostgreSQL：只允许
UPDATE table_name SET ... FROM ...，FROM只提供关联数据源，SET只能更新目标表字段；想改归档表？得另起一条UPDATE - SQL Server：类似，
UPDATE t1 SET ... FROM t1 JOIN t2 ...中t2仅作条件/计算用，SET不能引用t2的列进行赋值 - 任何尝试在
SET中写t2.col = ...都会触发明确报错，如 PostgreSQL 的column "t2.col" does not exist
安全可靠的替代方案：事务 + 分步更新
真正保证主表和归档表数据一致的唯一通用做法，是显式控制执行顺序和原子性：
- 用
BEGIN TRANSACTION（或BEGIN）包裹两步操作 - 先更新主表（例如标记为已归档：
UPDATE orders SET status = 'archived' WHERE id = 123） - 再更新归档表（例如同步状态：
UPDATE orders_archive SET status = 'archived' WHERE order_id = 123） - 最后
COMMIT；任一步失败则ROLLBACK - 注意：归档表需有对应主键/外键约束，且更新条件必须严格对齐（比如都用
order_id，而非依赖时间戳或模糊匹配）
更健壮的做法：用存储过程封装逻辑
把双表更新封装成带参数的存储过程，能复用、加校验、统一错误处理：
CREATE PROCEDURE archive_order(IN p_order_id INT)
BEGIN
DECLARE EXIT HANDLER FOR SQLEXCEPTION
ROLLBACK;
START TRANSACTION;
UPDATE orders SET archived_at = NOW(), status = 'archived' WHERE id = p_order_id;
UPDATE orders_archive SET status = 'archived', archived_at = NOW() WHERE order_id = p_order_id;
COMMIT;
END;
调用：CALL archive_order(123)。这样既避免手写事务遗漏，也防止应用层因网络中断导致只更新了一半。
跨表更新最常被忽略的点是：没有验证归档表是否真有对应记录。如果 orders_archive 缺少 order_id = 123 的行，第二条 UPDATE 影响行为 0，但事务仍会提交——数据已不一致。务必在存储过程中加 ROW_COUNT() 检查，或提前用 INSERT ... ON CONFLICT（PostgreSQL）/ MERGE（SQL Server）确保归档行存在。
