临时表+JOIN更新比WHERE IN快，但需主键/唯一索引防笛卡尔积，目标表关联字段也须索引，临时表生命周期绑定会话而非事务，跨事务不自动清空数据。
临时表 + JOIN 更新比 WHERE IN 快，但必须加主键
直接把几万 ID 塞进 WHERE id IN (1,2,3,...) 会导致 MySQL 解析慢、执行计划崩、甚至报错 Packet too large。临时表能绕过这个瓶颈，但前提是它得有主键或唯一索引——否则 UPDATE ... JOIN 会退化成笛卡尔积，EXPLAIN 显示 type=ALL，实际扫描行数爆炸。
-
CREATE TEMPORARY TABLE tmp (id BIGINT PRIMARY KEY, new_status TINYINT)是安全写法；CREATE TEMPORARY TABLE AS SELECT不带PRIMARY KEY，列类型还可能变成VARBINARY，JOIN 时隐式转换失败 - 目标表的关联字段（如
users.id）也得有索引，否则即使临时表有主键，UPDATE 还是全表扫 - 单次插入别超 5000 行，防
max_allowed_packet溢出；用LOAD DATA INFILE或客户端流式COPY（PostgreSQL）比多条INSERT快 5–10 倍
MySQL、PostgreSQL、SQL Server 的临时表写法不能混用
抄错语法直接报错，不是逻辑问题而是解析失败。
- MySQL：用
CREATE TEMPORARY TABLE tmp (...) ENGINE=InnoDB，更新写成UPDATE t1 JOIN tmp ON t1.id = tmp.id SET ... - SQL Server：本地临时表名带单个
#，比如#tmp，更新必须用FROM语法：UPDATE t1 SET t1.status = t2.new_status FROM users t1 JOIN #tmp t2 ON t1.id = t2.id - PostgreSQL：
SELECT ... INTO TEMP TABLE tmp必须把INTO TEMP TABLE放在SELECT末尾，顺序错就报syntax error at or near "INTO"
临时表生命周期不等于事务生命周期
这是最常卡住人的点：临时表绑定的是会话（session），不是事务（transaction）。
- 在事务里
CREATE TEMPORARY TABLE后ROLLBACK，表依然存在；断开连接才自动销毁，不用手动DROP TEMPORARY TABLE - 别指望跨事务复用同一张临时表——事务提交后表还在，但下个事务里你得重新
INSERT数据，上个事务写入的内容不会保留 - 如果批量更新要分多批跑，每批都该重建临时表，而不是往已有表里
INSERT追加，否则残留数据会干扰后续批次
不是所有场景都适合临时表 + JOIN
它只在“有明确关联键 + 数据可一次性加载 + 目标表有对应索引”时提效；条件不满足反而更慢。
- 用模糊匹配（如
WHERE name LIKE '%abc%'）或 TEXT 字段做关联，临时表无法走索引，JOIN 效率不如直接 WHERE - 数据源来自外部 API 流式返回，无法缓存成完整临时表，此时应改用
id BETWEEN分批 - 单次更新量小于 500 行，临时表创建、插入、销毁的开销可能超过收益
- 目标表关联字段没索引，建索引成本高于更新本身，那就先建索引再跑，别硬扛
临时表不是语法糖，它是把计算和应用分离的工程选择——数据落地成结构，才能让优化器真正看懂你在做什么。最容易被忽略的，是建完表不加索引、目标表没配索引、以及误以为临时表能跨事务存活。
