临时表+JOIN是解决复杂批量更新最稳的方案，但需建索引、用INNER JOIN、控制数据量；否则比子查询更慢，因其将“逻辑复用”升级为“物理复用”，通过索引连接避免逐行子查询。
临时表 + JOIN 是解决复杂批量更新最稳的路，但必须建索引、用 INNER JOIN、控制数据量，否则比原生子查询还慢。
为什么 UPDATE ... JOIN 比子查询快一个数量级
MySQL 执行 UPDATE t1 SET x = (SELECT y FROM t2 WHERE t2.id = t1.ref_id) 时，每更新一行都会重新执行一次子查询——优化器无法复用结果，常退化为 DEPENDENT SUBQUERY，EXPLAIN 显示 rows 接近全表行数。而用临时表后走 ref 或 eq_ref 连接，数据库只需做一次哈希连接或索引查找，匹配全部目标行。
关键差异在于：子查询是“逻辑复用”，临时表是“物理复用”。中间结果落地成结构化表，让优化器能真正走索引嵌套循环。
- 临时表必须对关联字段（如
order_id）显式声明PRIMARY KEY或UNIQUE INDEX，否则 JOIN 会退化为笛卡尔积 - 目标表的对应字段（如
orders.id）也得有索引，否则 UPDATE 仍会全表扫描 - 别用
CREATE TEMPORARY TABLE AS SELECT直接建表——它不支持PRIMARY KEY语法糖，容易漏索引
怎么写一个安全可复用的临时表更新流程
三步不可省、顺序不能乱：建表 → 写入 → 关联更新。每一步都有明确约束。
- 建表用
CREATE TEMPORARY TABLE tmp_updates (id BIGINT PRIMARY KEY, status TINYINT NOT NULL)，类型与目标表严格对齐；含表达式（如DATE(created_at)）时务必CAST，避免隐式转换失败 - 写入优先用
INSERT INTO tmp_updates VALUES (1,2), (2,3), ...，单批 ≤ 1000 行，防max_allowed_packet超限；不要用客户端拼 SQL 循环 INSERT - 更新必须用
UPDATE orders o INNER JOIN tmp_updates t ON o.id = t.id SET o.status = t.status；禁用LEFT JOIN，否则没匹配上的行会被设为NULL
哪些情况临时表反而更慢或不可行
不是所有批量更新都适合这条路。踩坑往往发生在没判断清楚前提条件时。
- 更新依据是模糊条件（如
WHERE name LIKE '%abc%'），临时表无法高效关联 - 数据源来自流式 API，无法一次性缓存成完整临时表（此时应改用
WHERE id BETWEEN分片） - 目标表关联字段无索引且建索引成本过高（比如只有 TEXT 字段）
- 单次更新量
容易被忽略的一点：临时表生命周期绑定会话，不是事务
在事务里建临时表没问题，但别指望跨事务复用——断开连接就销毁，DROP TEMPORARY TABLE 不是必须的。更隐蔽的风险是：如果程序用了连接池，同一会话可能被复用，残留的临时表会干扰后续操作。建议每次使用前加 DROP TEMPORARY TABLE IF EXISTS tmp_updates，哪怕多一次解析也比数据错乱强。
