最稳方式是用UPDATE ... JOIN一次性更新多列，避免多次单列更新或IN(SELECT)；MySQL不支持UPDATE...FROM和隐式逗号连接，必须显式JOIN并确保关联字段有索引，复杂逻辑需用派生表封装。
直接用 UPDATE ... JOIN 一次性更新多列最稳，别写多个单列 UPDATE 或硬套 IN (SELECT) —— 前者网络开销大、锁竞争高，后者在 MySQL 5.7 及更早版本会报 You can't specify target table 'xxx' for update in FROM clause。
MySQL 多表 JOIN 更新必须显式写出 JOIN 关键字
MySQL 不支持标准 SQL 的 UPDATE ... FROM，也不能用逗号隐式连接表。写成 UPDATE t1, t2 SET ... WHERE t1.id = t2.id 虽然能跑，但可读性差、严格模式下可能被拒绝，且无法控制关联逻辑。
- 正确语法是
UPDATE t1 JOIN t2 ON t1.id = t2.t1_id SET t1.col1 = t2.val1, t1.col2 = t2.val2 - 被更新的表（
t1）必须明确出现在UPDATE后，不能只写别名 - 如果要更新三张表的字段，得逐层 JOIN：
UPDATE t1 JOIN t2 ON ... JOIN t3 ON ... SET t1.a = t2.x, t1.b = t3.y - 所有 JOIN 条件字段（如
t2.t1_id、t3.t2_id）必须有索引，否则大表下全表扫描+慢到卡死
复杂规则必须拆成子查询派生表再 JOIN
当更新值依赖聚合、分组或跨路径查表（比如“取每个用户的最新订单金额”或“主变高压侧电压等级”），不能把子查询直接塞进 WHERE 或 SET，而要先封装成带别名的派生表（derived table），再和主表 JOIN。
- 错误写法：
UPDATE users SET last_order_amount = (SELECT amount FROM orders WHERE user_id = users.id ORDER BY created_at DESC LIMIT 1)—— MySQL 5.7 报错；8.0+ 虽支持，但性能差、不可控 - 正确写法：用两层 JOIN，第一层找最大时间，第二层取对应订单：
UPDATE users u JOIN (SELECT user_id, MAX(created_at) AS max_time FROM orders GROUP BY user_id) latest ON u.user_id = latest.user_id JOIN orders o ON o.user_id = latest.user_id AND o.created_at = latest.max_time SET u.last_order_amount = o.amount - 注意：派生表必须起别名（如
latest），否则语法报错 - 若某用户无订单，该行不会被更新（
last_order_amount保持原值），这不是 SQL 没生效，而是JOIN语义本身如此
批量更新多列时最容易忽略的三个细节
多列更新看着只是多写几个 =，但实际执行中出错往往藏在细节里。
-
SET子句里不能调用NOW()等非确定性函数多次——比如SET a = NOW(), b = NOW()可能产生两个不同毫秒值，影响业务逻辑一致性；应统一用变量或一次计算 - 更新字段如果有
NOT NULL约束，但关联表对应值为NULL（比如t2.new_price IS NULL），那这列会被设成NULL并触发约束报错；加WHERE t2.new_price IS NOT NULL过滤，或用COALESCE(t2.new_price, 0) - 务必检查
JOIN结果是否唯一：如果t2中一条记录匹配t1多条，MySQL 会随机选一条更新，结果不可控；先跑SELECT COUNT(*) FROM t1 JOIN t2 ON ... GROUP BY t1.id HAVING COUNT(*) > 1验证
真正复杂的批量更新，难点不在语法，而在关联路径是否收束、NULL 是否被显式处理、以及 JOIN 结果是否唯一——这些地方不提前验证，上线后数据错乱很难回溯。
