临时表+join比where in更快，因后者参数膨胀致解析和执行计划变重，前者通过物理表结构支持索引嵌套循环，避免全表扫描；需为临时表和目标表关联字段建主键或索引，且更新须用inner join。
为什么临时表 + JOIN 比 WHERE IN 更快
因为 WHERE id IN (1,2,3,...,10000) 本质是把上万 ID 塞进一条 SQL，MySQL 解析、参数绑定、执行计划生成都变重；而临时表 + JOIN 把数据“落地”成物理结构，让优化器能走索引嵌套循环（ref 或 eq_ref），避免全表扫描和参数膨胀。
常见错误现象：EXPLAIN 显示 type=ALL 或 rows 接近全表行数；执行时 CPU 飙高、锁等待超时。
- 临时表必须建主键或唯一索引（如
user_id INT PRIMARY KEY），否则JOIN会退化为笛卡尔积 - 目标表的关联字段（如
users.id）也得有索引，否则UPDATE还是扫全表 - 别用
CREATE TABLE ... SELECT直接建临时表——它不支持PRIMARY KEY语法糖，容易漏索引
怎么写一个安全可复用的临时表更新语句
核心是三步：建表 → 写入 → 关联更新。不能省略任何一步，也不能颠倒顺序。
示例场景：用程序导出的 5 万条新状态，批量更新 orders 表的 status 字段：
CREATE TEMPORARY TABLE tmp_order_updates ( order_id BIGINT PRIMARY KEY, new_status TINYINT NOT NULL );
INSERT INTO tmp_order_updates VALUES (1001, 2), (1002, 3), ...（每批 ≤ 1000 行，防 max_allowed_packet 超限）
最后执行更新：
UPDATE orders o INNER JOIN tmp_order_updates t ON o.id = t.order_id SET o.status = t.new_status;
- 务必用
INNER JOIN，不是LEFT JOIN——后者可能意外清空没匹配上的行 -
SET子句里别调用NOW()、UUID()等非确定性函数，会导致执行计划不稳定 - 如果更新后要查影响行数，用
SELECT ROW_COUNT()，别依赖客户端返回值（有些驱动会丢）
哪些情况不适合用临时表 + JOIN
不是所有批量更新都适合这条路。当出现以下任一条件，该方案反而更慢或不可行：
- 更新依据不是主键/唯一键，而是模糊条件（如
WHERE name LIKE '%abc%'），临时表无法高效关联 - 数据源来自外部 API 流式返回，无法一次性缓存成完整临时表（此时应改用分批
WHERE id BETWEEN） - 目标表无任何索引可用于
JOIN条件（比如只有TEXT字段），建索引成本高于更新本身 - 单次更新量小于 500 行——临时表开销（创建、插入、销毁）可能超过收益
容易被忽略的一点：临时表在事务中创建，但 DROP TEMPORARY TABLE 不是必须的；连接断开时自动清理。但如果脚本里显式 DROP，得确保它在 UPDATE 之后、COMMIT 之前执行，否则下次重跑会报错表不存在。
