MySQL多表UPDATE必须用显式JOIN语法，禁用隐式JOIN；只能更新UPDATE子句列出的表；WHERE条件需匹配JOIN结果集；避免SET中嵌套子查询；注意索引、锁和事务重试。
MySQL多表UPDATE语法结构必须用JOIN
MySQL不支持标准SQL的UPDATE ... FROM写法，直接写UPDATE t1, t2 SET t1.col = t2.col WHERE t1.id = t2.t1_id虽然能运行，但属于隐式JOIN，可读性差、易出错，且在严格模式下可能被拒绝。正确做法是显式使用JOIN关键字，把关联逻辑和更新目标分离清楚。
常见错误现象：执行后0行受影响，但没报错——往往是因为WHERE条件没匹配到数据，或JOIN类型选错导致结果集为空。
- 必须写
UPDATE t1 JOIN t2 ON ...，不能省略JOIN关键字 -
SET子句中只能更新UPDATE后面列出的表（即主表），不能更新JOIN进来的表字段 - 如果要更新多个表，需把它们都列在
UPDATE后，如UPDATE t1, t2，再用JOIN连接第三张表
UPDATE多表时WHERE条件必须落在JOIN结果集上
很多人习惯把过滤条件写在WHERE里，比如想只更新状态为'pending'的订单及其对应用户积分，却把t1.status = 'pending'放在WHERE末尾——这没问题；但如果误写成t2.is_active = 1而t2又用了LEFT JOIN，就可能导致t2字段为NULL，整行被排除，更新失败。
更安全的做法是把关键过滤条件尽量前置到ON子句或确保JOIN类型匹配业务语义：
- 确定关联必存在的，用
INNER JOIN，条件放ON或WHERE都行 - 允许关联缺失的，用
LEFT JOIN，但WHERE中避免对右表字段做非空判断（如t2.id IS NOT NULL），否则退化为INNER JOIN - 执行前先用
SELECT模拟：把UPDATE换成SELECT *，确认结果集行数和内容符合预期
小心子查询嵌套导致性能崩盘
有人为图省事，在SET里写子查询，比如SET t1.score = (SELECT SUM(amount) FROM orders o WHERE o.user_id = t1.id)。这种写法在小数据量下看似可行，但MySQL会为每一行t1执行一次子查询，N×M复杂度，万级数据就明显卡顿。
替代方案是用JOIN聚合预计算：
UPDATE users u JOIN ( SELECT user_id, SUM(amount) AS total FROM orders GROUP BY user_id ) o ON u.id = o.user_id SET u.total_spent = o.total;
这样聚合只做一次，JOIN走索引的话效率高得多。注意：子查询必须有别名（如这里的o），否则MySQL报错Every derived table must have its own alias。
事务与锁行为容易被忽略
多表UPDATE不是原子操作的“幻觉”——它会按顺序扫描并加锁，涉及的表越多、范围越大，锁持有时间越长。如果同时有其他事务在更新同一组记录，极易触发死锁，错误信息是Deadlock found when trying to get lock。
降低风险的关键动作：
- 确保
JOIN字段和WHERE字段都有索引，避免全表扫描锁表 - 限制更新范围，加
LIMIT（MySQL 5.6+支持多表UPDATE带LIMIT） - 在应用层用事务包裹，并捕获
Deadlock异常做重试，不要依赖单次执行成功
跨表UPDATE真正难的从来不是语法，而是理解它背后触发的锁粒度和执行计划——写完立刻EXPLAIN UPDATE ...（MySQL 8.0.19+支持）比盲目执行更省时间。
