跨库UPDATE必须用JOIN，不能用子查询引用其他库表；正确写法是UPDATE目标表JOIN源表ON关联条件SET目标表字段=源表字段，并需权限、别名、索引和事务保障。
跨库 UPDATE 必须用 JOIN，不能直接写 db1.t1 SET col = (SELECT ... FROM db2.t2)
MySQL 的 UPDATE 语句语法不允许在 SET 或 WHERE 子句中“隐式引用”其他数据库的表作为数据源。你写不出 UPDATE db1.users SET email = (SELECT email FROM db2.user_info WHERE user_id = users.id) 这种形式——它会报 ERROR 1064 或更明确的 ERROR 1103（Incorrect table name）。根本原因是：UPDATE 要求所有参与表都显式出现在 UPDATE ... JOIN ... 结构中，且只能更新 UPDATE 后声明的那个表。
正确做法是把目标表放前面，用 JOIN 拉入源表：
UPDATE db1.users u JOIN db2.user_info ui ON u.id = ui.user_id SET u.email = ui.email;
- 必须给两个表加别名（如
u、ui），否则字段歧义会导致语法错误 -
SET只能更新UPDATE后第一个表（这里是u），不能写ui.email = ... - 如果要加过滤条件，写在
WHERE里（比如WHERE ui.status = 'active'），但注意：它作用于整个 JOIN 结果集，不是仅对源表生效
大批量跨表更新别硬扛，优先用临时表 + JOIN
当你要更新几万行，或源数据来自复杂查询（比如聚合、子查询、外部导入），硬写几十个 CASE WHEN 或超长 IN 列表，容易触发锁表、超时、内存溢出，甚至被 max_allowed_packet 截断。
更可控的方式是分两步：先建临时表存更新映射，再用 UPDATE ... JOIN 批量回写：
CREATE TEMPORARY TABLE temp_update_map ( id INT PRIMARY KEY, new_email VARCHAR(255) ); INSERT INTO temp_update_map VALUES (1, 'a@x.com'), (2, 'b@y.com'), (3, 'c@z.com'); UPDATE db1.users u JOIN temp_update_map t ON u.id = t.id SET u.email = t.new_email;
- 临时表用
CREATE TEMPORARY TABLE，会话结束自动销毁，比普通表安全 -
id字段必须建主键或唯一索引，否则JOIN性能暴跌——没索引时 MySQL 可能走嵌套循环全表扫描 - 插入数据可用
LOAD DATA INFILE或客户端批量INSERT，比拼 SQL 字符串更稳
事务包裹跨表更新是底线，但要注意锁范围和顺序
跨表更新天然涉及多个表，哪怕只更新一个目标表，只要 JOIN 了另一库的表，InnoDB 就会对两个表的相关行加锁（通常是 record lock + gap lock）。不加事务，失败时无法回滚，极易留下脏数据。
必须用 START TRANSACTION 包裹：
START TRANSACTION; UPDATE db1.users u JOIN db2.user_info ui ON u.id = ui.user_id SET u.email = ui.email WHERE ui.updated_at > '2026-09-01'; -- 先 SELECT 验证影响行数 SELECT COUNT(*) FROM db1.users u JOIN db2.user_info ui ON u.id = ui.user_id WHERE ui.updated_at > '2026-09-01'; COMMIT;
- 执行前务必用
SELECT模拟匹配逻辑，确认行数合理；否则一个错位的ON条件可能误更新全部数据 - 如果同时操作多个目标表（比如还要更新
db1.profiles），把它们全塞进同一个事务块，按固定顺序（如按库名/表名字典序）访问，降低死锁概率 - 权限检查更严格：用户需同时具备对
db1.users的UPDATE权限，和对db2.user_info的SELECT权限
MySQL 8.0+ 可用 CTE + 窗口函数做原子化序号更新
如果你的需求是“给某表每行重算连续序号”，传统方案（@rn:=@rn+1）在 MySQL 8.0+ 已不可靠：变量作用域混乱、并发结果不确定、无法在单条 UPDATE 中初始化并复用。
现代写法用 WITH + ROW_NUMBER()，一行 SQL 完成，事务安全：
WITH cte AS ( SELECT id, ROW_NUMBER() OVER (ORDER BY id) AS rn FROM nl_emails ) UPDATE nl_emails e JOIN cte ON e.id = cte.id SET e.row_num = cte.rn;
- 必须有唯一列（如
id）用于JOIN关联，否则多匹配会导致重复更新或丢失 -
ORDER BY可换为业务字段（如created_at、email），但排序字段最好有索引 - 执行前先跑
SELECT版本验证序号逻辑，避免误覆盖
真正容易被忽略的是：这个方案依赖 MySQL ≥ 8.0，且 ROW_NUMBER() 计算是一次性完成的，不会因 JOIN 顺序或执行计划变化而错乱——这是它比用户变量强的核心原因。
