MySQL 8.0前UPDATE不能直接引用目标表，需用内联视图绕过ERROR 1093；PostgreSQL用UPDATE...FROM且FROM后仅限单表或子查询；SQL Server的UPDATE...FROM易因重复匹配静默覆盖；三者均需注意NULL处理、索引优化与分批控制。
MySQL 8.0 之前无法直接在 UPDATE 的 FROM 或子查询中引用目标表，否则报错 ERROR 1093 (HY000): You can't specify target table 't' for update in FROM clause；PostgreSQL 和 SQL Server 没这限制，但语法和行为差异极大——不能照搬写法。
MySQL 报 ERROR 1093？必须用内联视图套一层
这不是语法写错了，是 MySQL 引擎主动拦截「读自己又改自己」的操作。绕过方法只有一种：把子查询包成派生表（即内联视图），并强制加别名。
-
SELECT必须嵌套在FROM ( ... ) AS tmp里，tmp不能省，也不能用保留字如AS order - 外层
WHERE或JOIN条件必须显式关联到主表字段，比如o1.user_id = tmp.user_id - 如果子查询里要 GROUP BY 或 DISTINCT，得确保结果对主表每行最多匹配一次，否则可能触发多行更新警告
- 示例（修复订单状态）：
UPDATE orders o1 INNER JOIN ( SELECT DISTINCT o2.user_id FROM orders o2 INNER JOIN payments p ON o2.id = p.order_id WHERE p.created_at > NOW() - INTERVAL 30 DAY ) AS tmp ON o1.user_id = tmp.user_id SET o1.status = 'paid_recently';
PostgreSQL 用 UPDATE ... FROM，但别乱写 JOIN
PostgreSQL 不支持 UPDATE ... JOIN，必须用 UPDATE ... FROM，且 FROM 后只能跟一个表或子查询，不能逗号拼接，也不能再写 JOIN 关键字。
-
FROM子句里的表是只读的，仅提供数据源；更新目标仍是UPDATE后面那个表 - 关联逻辑全靠
WHERE里的等值条件，比如users.id = agg.user_id，漏写就变笛卡尔积 - 聚合子查询必须按目标表主键
GROUP BY，否则报错more than one row returned by a subquery - 示例（按用户订单数更新等级）：
UPDATE users u SET tier = CASE WHEN agg.order_cnt >= 10 THEN 'gold' WHEN agg.order_cnt >= 3 THEN 'silver' ELSE 'bronze' END FROM ( SELECT user_id, COUNT(*) AS order_cnt FROM orders WHERE created_at > '2025-01-01' GROUP BY user_id ) AS agg WHERE u.id = agg.user_id;
SQL Server 的 UPDATE ... FROM 容易静默出错
SQL Server 允许 UPDATE ... FROM，但它不校验关联唯一性：如果子查询对同一主表 ID 返回多行，它会静默执行多次更新，最终只保留最后一次的结果——你根本不知道哪条生效了。
- 务必在子查询里用
ROW_NUMBER() OVER (PARTITION BY id ORDER BY updated_at DESC)去重取最新 - 避免用旧式隐式 JOIN（
UPDATE t1, t2 SET ... WHERE t1.id = t2.t1_id），可读性差且易漏条件 - 若源表有重复键，
EXISTS+ 标量子查询反而更安全，虽然性能略低 - 示例（取最新发货状态）：
UPDATE o SET status = s.new_status FROM orders o INNER JOIN ( SELECT order_id, new_status, ROW_NUMBER() OVER (PARTITION BY order_id ORDER BY updated_at DESC) AS rn FROM shipments ) s ON o.id = s.order_id AND s.rn = 1;
跨数据库通用陷阱：NULL、索引和批量控制
无论用哪种语法，这三个点最容易被忽略，却直接决定更新是否成功、安全、可控。
- 子查询没匹配到数据时，默认写入
NULL，不是跳过——要用WHERE EXISTS(...)或COALESCE()显式兜底 - 子查询中的关联字段（如
payments.order_id）必须有索引，否则每行都触发全表扫描，10 万行可能跑十几分钟 - 单次更新超 5 万行，建议拆成
WHERE id BETWEEN x AND y分批，避免长事务锁表、日志暴涨或 OOM
