临时表+JOIN比WHERE IN快，因为IN需解析超长SQL字符串、参数绑定和生成执行计划，而临时表将数据物理落地为结构化表，使优化器能走ref或eq_ref索引查找，避免全表扫描。
临时表 + JOIN 为什么比 WHERE IN 快？
因为 WHERE id IN (1,2,3,...,50000) 实际是把 5 万 ID 全塞进一条 SQL，MySQL 要解析超长字符串、做参数绑定、生成执行计划——每一步都变重；而临时表把数据“落地”成带结构的物理表，优化器能走 ref 或 eq_ref 索引查找，避免全表扫描。
常见错误现象：EXPLAIN 显示 type=ALL 或 rows 接近目标表总行数；执行时 CPU 飙高、锁等待超时。
- 临时表没建主键或唯一索引 → JOIN 退化为笛卡尔积
- 目标表关联字段（如
users.id）没索引 → UPDATE 还是扫全表 - 用
CREATE TEMPORARY TABLE AS SELECT建表 → 不支持PRIMARY KEY语法糖，列类型可能变成VARBINARY，后续 JOIN 失败
MySQL 临时表更新三步必须严格按顺序
建表 → 写入 → 关联更新，缺一不可，顺序不能颠倒。
示例：用程序导出的 5 万条新状态，批量更新 orders 表的 status 字段：
CREATE TEMPORARY TABLE tmp_order_updates ( order_id BIGINT PRIMARY KEY, new_status TINYINT NOT NULL );
插入注意分批，每批 ≤ 1000 行，防 max_allowed_packet 超限：
INSERT INTO tmp_order_updates VALUES (1001, 2), (1002, 3), ...;
最后执行更新：
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()，别依赖客户端返回值（有些驱动会丢）
SQL Server 和 PostgreSQL 的写法差异很致命
抄错语法直接报错，不是兼容问题，是语法不认：
- MySQL：用
CREATE TEMPORARY TABLE tmp (...) ENGINE=InnoDB，更新用UPDATE t1 JOIN tmp ON ... 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必须放在SELECT末尾，顺序错就报syntax error at or near "INTO"
临时表生命周期和事务边界容易混淆
临时表绑定的是会话（session），不是事务（transaction）——这是卡住最多人的点：
- 在事务里创建临时表后，即使
ROLLBACK，临时表依然存在；断开连接才自动销毁，不用DROP TEMPORARY TABLE - 别指望跨事务复用同一个临时表：事务提交后表还在，但下个事务里你得重新
INSERT数据，不能依赖上个事务写入的内容 - 如果批量更新要分多批跑，每批都该重建临时表，而不是往已有临时表里追加——避免数据残留干扰
临时表不是银弹，它只在“有明确关联键 + 数据可一次性加载 + 目标表有对应索引”时才真正提效；一旦用模糊匹配或 TEXT 字段做关联，反而比直接 WHERE 更慢。
