MySQL不支持UPDATE...FROM语法，报ERROR 1064；正确写法是UPDATE...JOIN，且必须显式开启事务确保数据一致性。
UPDATE FROM 是 SQL Server 特有的语法，MySQL 和 Oracle 不支持。如果你在 MySQL 里直接写 UPDATE ... FROM，会报错 ERROR 1064 (42000) —— 这是最常踩的第一个坑。
UPDATE ... JOIN 是 MySQL 多表更新的正解
MySQL 不认 UPDATE FROM，但支持 UPDATE ... JOIN（包括 INNER JOIN、LEFT JOIN），语法更接近查询语句，也更容易验证逻辑。
-
UPDATE后面只能跟目标表（或别名），不能跟FROM -
JOIN必须出现在UPDATE和SET之间 -
SET中赋值的列必须属于目标表，不能写被 JOIN 表的字段（除非用子查询）
✅ 正确示例（更新 orders 表的 customer_name 字段，来自 customers 表）：
UPDATE orders o INNER JOIN customers c ON o.customer_id = c.id SET o.customer_name = c.name;
⚠️ 常见错误：
- 写成
UPDATE orders FROM customers ...→ 直接语法错误 - 在
SET里写c.name = o.customer_name→ 报错“Unknown column 'c.name' in 'field list'” - JOIN 条件漏索引（如
customer_id无索引）→ 执行变慢，甚至锁表
多表更新必须包在事务里，否则数据一定不一致
跨表更新不是“多条 UPDATE 拼一起”就完事。哪怕只差几毫秒，中间出错或并发写入，就会导致订单已更新、库存没扣减，或者用户状态变了但日志没记。
- MySQL 默认是自动提交，
START TRANSACTION必须显式写 - 所有涉及的
UPDATE、INSERT、DELETE必须在同一个BEGIN/COMMIT块中 - 存储过程中遇到异常（比如外键冲突、库存不足），要立刻
ROLLBACK，不能只靠应用层捕获 - 避免在事务里做非数据库操作（HTTP 调用、文件读写），否则锁表时间不可控
示例结构：
BEGIN; UPDATE users SET status = 'active' WHERE id = 123; UPDATE user_profiles SET last_login = NOW() WHERE user_id = 123; -- 中间加校验：SELECT @stock := stock FROM inventory WHERE item_id = 456; -- IF @stock < 1 THEN ROLLBACK; LEAVE proc_label; END IF; COMMIT;
子查询 vs JOIN：什么情况下该换写法
UPDATE ... JOIN 看起来简洁，但一碰到以下情况，建议改用子查询或 CTE：
- 被 JOIN 的表需要聚合（比如用
MAX(created_at)取最新记录） - 关联条件复杂，含多个 OR 或函数（如
DATE(order_time) = CURDATE()），容易索引失效 - 要更新的目标行在 JOIN 后出现重复（一对多时，
UPDATE可能静默执行多次，结果不可预期）
✅ 安全替代写法（MySQL 8.0+）：
UPDATE orders SET customer_name = ( SELECT c.name FROM customers c WHERE c.id = orders.customer_id ) WHERE customer_id IN (SELECT id FROM customers WHERE status = 'valid');
⚠️ 注意点：
- 子查询必须返回至多一行，否则报错
Subquery returns more than 1 row - 外层
WHERE和子查询里的WHERE要对齐，否则可能更新空集或全表 -
IN (SELECT ...)在大数据量下性能差，可改用EXISTS或临时表预过滤
最麻烦的从来不是写不出语句，而是：
-
WHERE少一个等号，把全表状态刷成一样； -
JOIN条件字段没索引，开发环境不卡，上线后慢成阻塞； - 事务里混了 MyISAM 表（非事务引擎），
ROLLBACK对它完全无效。
动手前，先用 SELECT 把关联结果查出来，确认行数和内容；再用 EXPLAIN 看执行计划，type 别是 ALL。
