mysql update join语法必须显式指定目标表（如update orders o），join写在表名后、set前，仅能更新目标表字段，不支持left join未匹配行更新，where须置于末尾过滤。
MySQL中UPDATE JOIN语法怎么写
MySQL支持直接在 UPDATE 语句中用 JOIN 关联多表更新，但语法和标准SQL不同：必须显式写出要更新的表名（或别名）在 UPDATE 后，且 JOIN 必须放在 SET 前。
常见错误是照搬SELECT的JOIN写法，漏掉目标表声明，导致报错 ERROR 1064 或 ERROR 1109（unknown table）。
正确写法示例：
UPDATE orders o JOIN customers c ON o.customer_id = c.id SET o.status = 'shipped', c.last_order_date = NOW() WHERE o.id = 123;
-
orders o是被更新的主表，o是它的别名，后续SET中必须用这个别名引用字段 -
JOIN只能是INNER JOIN；如果想用LEFT JOIN效果，需改用子查询或临时表，否则不匹配的行不会被更新（也不会报错） -
WHERE条件建议加上，否则可能意外更新大量行——MySQL不会像PostgreSQL那样要求明确限定范围
PostgreSQL里UPDATE FROM能不能替代JOIN
PostgreSQL不支持 UPDATE ... JOIN，但提供 UPDATE ... FROM 语法，功能等价，但语义和行为有关键区别。
典型写法：
UPDATE orders SET status = 'shipped', updated_at = NOW() FROM customers WHERE orders.customer_id = customers.id AND customers.country = 'CN' AND orders.id = 123;
-
FROM后的表不是被更新对象，仅用于提供关联条件和字段值；SET中不能直接引用customers的字段，除非在表达式里（如status = customers.preferred_status） - 如果
FROM表有多行匹配同一行orders，PostgreSQL会任意选一行（无警告），结果不可预测——这是最常踩的坑 - 若需确保一对一匹配，应在
FROM子句中用子查询加LIMIT 1或提前去重
SQL Server的UPDATE + FROM和别名陷阱
SQL Server用 UPDATE ... FROM，但语法更接近MySQL的JOIN风格，且允许给源表起别名——但别名不能和目标表重复，也不能省略目标表前缀。
正确示例：
UPDATE o SET o.status = 'shipped', c.last_contact = GETDATE() FROM orders o INNER JOIN customers c ON o.customer_id = c.id WHERE o.id = 123;
-
UPDATE o中的o必须和FROM中定义的别名一致，否则报错Msg 107（列前缀不匹配） - 不能写成
UPDATE orders SET ... FROM orders o JOIN ...，因为orders和o被视为不同标识符，字段引用会失败 - 如果关联表有触发器，
UPDATE FROM可能绕过某些INSTEAD OF触发器逻辑，需实测验证
跨数据库移植时最容易忽略的兼容性点
看起来都是“更新A表，用B表数据”，但各数据库对NULL处理、重复匹配、事务可见性、锁行为差异极大。
- MySQL在
UPDATE JOIN中遇到NULL关联键，整行跳过（不报错）；PostgreSQL的FROM若ON条件为NULL，该行也不参与更新，但容易误判为逻辑遗漏 - 所有数据库在多表JOIN/ FROM 更新时，都默认使用行级锁，但锁定顺序依赖执行计划——高并发下可能引发死锁，尤其当多个UPDATE语句以不同顺序访问相同表时
- SQLite不支持任何类型的多表UPDATE语法，必须拆成两条单表语句+事务包裹，且无法原子化读取中间值
真正麻烦的往往不是语法写不对，而是没意识到某次更新在测试库跑得通，上线后因数据分布变化（比如关联字段出现大量NULL或重复值），导致部分行被静默跳过或重复更新。
