mysql中update join的正确语法是update表名join表名on条件set更新字段，不能写from子句，且仅最左侧表可被更新；其性能远超子查询，但需加where防误更新，并分批执行避免锁表。
UPDATE ... JOIN 语法到底怎么写才不报错
MySQL 中直接用 UPDATE 配合 JOIN 是可行的，但语法和普通 SELECT JOIN 不同：不能写 FROM 子句，JOIN 必须紧跟在 UPDATE 后面，且被更新的表必须明确出现在 JOIN 左侧（或用别名指明）。常见错误是照搬 SELECT 写法，比如：
UPDATE t1 SET t1.name = t2.name FROM t1 JOIN t2 ON t1.id = t2.id; -- ❌ 报错：语法错误
正确写法是：
UPDATE t1 JOIN t2 ON t1.id = t2.id SET t1.name = t2.name; -- ✅
- 如果要更新的表有别名，
SET中的列必须用该别名限定，如SET a.name = b.name，不能只写name - 多表 JOIN 时，只有最左侧的表（或显式指定的单个目标表）可被更新，其余表仅用于关联查值
- PostgreSQL 和 SQL Server 不支持这种写法，前者要用
UPDATE ... FROM，后者用UPDATE ... FROM ... JOIN，语法差异大，切勿混用
为什么比子查询 UPDATE 快得多
用 (SELECT ...) 子查询更新，比如 UPDATE t1 SET name = (SELECT name FROM t2 WHERE t2.id = t1.id)，会导致对 t1 每一行都执行一次子查询——全表扫描 + N 次索引查找，时间复杂度接近 O(n×m)。而 JOIN 方式让优化器能一次性走一次哈希连接或索引嵌套循环，实际执行计划通常显示为单次扫描 + 关联匹配。
- 当
t2表有id索引，且t1.id也有索引时，JOIN更新基本是 O(n + m) 级别 - 若没索引，两者都会变慢，但子查询方式恶化更明显，可能触发临时表或文件排序
- 实测百万级数据更新，有索引时
JOIN比子查询快 5–20 倍，取决于匹配率和字段大小
WHERE 条件必须加，否则容易误更新整张表
UPDATE ... JOIN 很容易漏掉 WHERE，结果就是把所有能 JOIN 上的行全更新了——哪怕你本意只想改其中一部分。更危险的是，如果 t2 中某 id 对应多条记录，JOIN 会生成笛卡尔积，导致同一行被反复更新（最终值取决于最后匹配到的那条），且影响行数统计失真。
- 务必在
SET前加上明确的WHERE，例如：UPDATE t1 JOIN t2 ON t1.id = t2.id SET t1.status = t2.status WHERE t2.updated_at > '2024-01-01' - 如果业务逻辑要求“只更新存在对应关系的行”，也建议显式加
WHERE t2.id IS NOT NULL（尽管INNER JOIN已隐含此意，但可读性更强） - 上线前先用
SELECT模拟：把UPDATE换成SELECT COUNT(*)，确认返回行数合理
大表更新时如何避免锁表和超时
即使语法和逻辑都对，一次性更新几百万行仍可能阻塞业务、触发 lock wait timeout 或撑爆 undo log。不能只依赖 SQL 写法优化，得配合执行策略：
- 加
LIMIT分批（MySQL 5.6+ 支持）：UPDATE t1 JOIN t2 ON t1.id = t2.id SET t1.val = t2.val WHERE t1.updated = 0 LIMIT 10000，再用脚本循环 - WHERE 条件尽量走索引，避免全表扫描；更新后记得
UPDATE t1 SET updated = 1标记，防止重复处理 - 避开高峰期执行；若有主从延迟敏感，考虑先在从库验证语句执行计划（
EXPLAIN UPDATE ...不支持，可用等价SELECT替代） - InnoDB 行锁在 UPDATE 时会升级为间隙锁或临键锁，若 WHERE 条件范围大，可能锁住大量无关行——这时按主键 ID 分段（如
WHERE id BETWEEN 100000 AND 200000）比按状态字段更安全
真正卡住人的往往不是语法，而是没意识到 JOIN 更新会锁住所有参与匹配的行，包括 t2 表中被扫描到的记录。这点在高并发场景下特别容易被忽略。
