MySQL根本不支持同时更新多张表，只能更新紧跟在UPDATE后的唯一目标表；其他表仅作数据源，SET中更新非目标表会报ERROR 1093。
MySQL根本不支持同时更新多张表
直接说结论：UPDATE语句在 MySQL 中**只能修改紧跟在 UPDATE 关键字后的那一张表**，其他表无论 JOIN 多少个、别名怎么写，都只是“只读”的数据源。试图在 SET 子句里更新非目标表（比如 SET t2.status = 'done'），会立刻报错：ERROR 1093 (HY000): You can't specify target table 't2' for update in FROM clause。
这个错误提示有误导性——它和 FROM 无关，本质是 MySQL 禁止“对正在被 UPDATE 的表做子查询”，而把非目标表写进 SET 左侧，会被解析为非法的目标表引用。
- 正确姿势：只更新一个目标表，用 JOIN 拉其他表字段来计算新值（如
SET t1.name = t2.full_name） - 错误姿势：
UPDATE t1 JOIN t2 ON ... SET t2.flag = 1—— 报错 - 别名冲突也报错：
UPDATE t1 a JOIN t2 a ON ...→ERROR 1066: Not unique table/alias
三张表关联时，怎么安全地更新其中一张？
常见场景：想根据 users 和 orders 的聚合结果，更新 users.vip_level；同时还要用 user_profiles 表里的 preferred_lang 做条件过滤。这时不能写三个 JOIN 后直接改三张表，但可以合法地只改 users，并用另外两张提供数据。
- 必须显式指定目标表别名，且所有
SET字段前缀必须匹配该别名（如u.vip_level） - 关联多张表时，
ON条件要逐级明确，避免隐式笛卡尔积（比如漏写t2.id = t3.t2_id） - WHERE 中的过滤条件作用于整个 JOIN 结果集，不是单表——所以
WHERE p.lang = 'zh'实际会过滤掉所有没匹配到user_profiles的用户行 - 先跑等价
SELECT验证：SELECT u.id, COUNT(o.id), p.lang FROM users u JOIN orders o ON u.id = o.user_id LEFT JOIN user_profiles p ON u.id = p.user_id GROUP BY u.id, p.lang HAVING COUNT(o.id) > 5 AND p.lang = 'zh'
想改多张表，只能分多次执行
如果业务上真需要原子性地更新两张表（比如扣款 + 记流水），MySQL 的 UPDATE 语法做不到，必须靠事务兜底。重点不是“怎么写一条语句”，而是“怎么拆得安全、可回滚、不丢数据”。
- 用显式事务包裹多个单表
UPDATE：BEGIN; UPDATE accounts SET balance = balance - 100 WHERE id = 123; UPDATE logs SET status = 'deducted' WHERE ref_id = 123; COMMIT; - 每条
UPDATE都要带WHERE，且检查affected_rows—— 如果第一条成功、第二条因ref_id不存在而影响行为 0，就得ROLLBACK - 避免在事务中做耗时操作（如调外部 API），否则长事务会锁表
- 高并发下注意死锁：统一按固定顺序更新表（比如永远先
accounts后logs），不要有时反着来
跨数据库兼容时，别碰 UPDATE JOIN
UPDATE ... JOIN 是 MySQL 特有语法，PostgreSQL 会报 ERROR: syntax error at or near "JOIN"，Oracle 直接抛 ORA-00971: missing SET keyword。如果你的代码要适配多种数据库，或者未来可能迁移，现在就该放弃这种写法。
- 优先用标准 SQL 的
UPDATE ... FROM（PostgreSQL）或MERGE INTO（Oracle）替代 - 最通用方案是子查询 +
EXISTS：UPDATE users SET last_login = (SELECT MAX(created_at) FROM sessions WHERE user_id = users.id) WHERE EXISTS (SELECT 1 FROM sessions WHERE user_id = users.id) - 哪怕 MySQL 也支持这种写法，且能避开
ERROR 1093（只要子查询不直接查被更新表）
真正容易被忽略的点是：JOIN 更新的 WHERE 条件一旦涉及 NULL（比如 WHERE t2.status IS NOT NULL），那些没匹配上 t2 的 t1 行就完全不会被更新——不是设成 NULL，而是跳过。这比误更新更难排查，因为日志里看不出异常。
