MySQL的UPDATE语句只能指定一个目标表，多表更新需通过JOIN引入非目标表，SET左侧字段必须属于目标表，WHERE须显式过滤，JOIN类型和索引/事务同样关键。
UPDATE后面只能跟一个目标表名
MySQL的UPDATE语句不支持多表更新语法，也不接受UPDATE t1, t2 SET ...或UPDATE FROM这种写法——后者是SQL Server/PostgreSQL的语法，直接照搬会报ERROR 1064。你必须明确指定**唯一被修改的表**，放在UPDATE关键字之后，其他表只能通过JOIN引入。
- 正确写法：
UPDATE users u JOIN orders o ON u.id = o.user_id SET u.last_order_amount = o.amount - 错误写法：
UPDATE users u, orders o SET u.last_order_amount = o.amount（旧式隐式连接，易错且不可控） - 更错写法：
UPDATE orders o JOIN users u ON ... SET u.status = 'active'（u不是UPDATE后声明的目标表，会报ERROR 1093）
SET左侧字段必须属于目标表，右侧可引用JOIN表字段
SET子句只能更新UPDATE后那个表的列，但右边可以取JOIN来的字段值——前提是加别名前缀，否则会因字段名重复报Column 'xxx' in field list is ambiguous。
- 允许：
SET u.updated_at = o.updated_at（o是JOIN表别名） - 禁止：
SET o.status = 'done'（o不是目标表） - 字段重名时必须写全：
SET u.name = o.name，不能只写SET name = o.name
WHERE必须显式写出，不能塞进ON里当业务过滤条件
ON只负责关联逻辑，WHERE才真正控制哪些行被更新。把业务条件（比如o.status = 'paid'）写在ON里，会导致LEFT JOIN时未匹配行也被纳入结果集，可能意外覆盖为NULL；而INNER JOIN下看似没影响，实则掩盖了逻辑歧义。
- 安全写法：
ON u.id = o.user_id WHERE o.status = 'paid' AND o.created_at > '2024-01-01' - 危险写法：
ON u.id = o.user_id AND o.status = 'paid'（尤其搭配LEFT JOIN时，极易误清数据） - 务必先用
SELECT * FROM users u JOIN orders o ON ... WHERE ...验证命中行数是否符合预期
LEFT JOIN和INNER JOIN行为差异直接影响更新范围
选哪种JOIN不是看“高级不高级”，而是看业务要不要保留主表中无关联记录的行。INNER JOIN天然过滤掉不匹配的行；LEFT JOIN会让所有主表行进入更新流程，但若SET右侧直接引用右表字段（如c.discount），没匹配时就会变成NULL，覆盖原值。
- 想只更新有订单的用户：
INNER JOIN orders o ON u.id = o.user_id - 想给所有用户设默认折扣，没订单的设为0：
LEFT JOIN orders o ON u.id = o.user_id SET u.discount = IFNULL(o.discount, 0) - 想把“无客户信息的订单”标记为异常：
UPDATE orders o LEFT JOIN customers c ON o.customer_id = c.id SET o.flag = 'orphan' WHERE c.id IS NULL
实际执行前最容易被忽略的是索引和事务。JOIN字段（如user_id）、WHERE字段（如created_at）没索引，大表一跑就卡死；没包在START TRANSACTION里，出错没法回滚——这两点不处理，再正确的SQL也容易翻车。
