临时表需手动控制生命周期、索引和数据规模，盲目使用反而更慢；必须显式建表+建索引、用inner join、严格类型对齐、及时drop，否则易引发全表扫描、隐式转换、连接复用冲突等问题。
临时表不是“自动提速开关”，而是需要你亲手控制生命周期、索引和数据规模的中间载体。直接用 CREATE TEMPORARY TABLE AS SELECT 写完就 JOIN，大概率比原生子查询还慢。
为什么 UPDATE + 临时表反而变慢？
常见错误是把临时表当“语法糖”用，忽略了优化器实际执行路径：
- 没建索引：临时表默认无任何索引，
UPDATE ... JOIN会退化为全表扫描，哪怕只有 5000 行 - 用错 JOIN 类型：写成
LEFT JOIN导致未匹配行被设为NULL，语义出错且无法利用索引 - 字段类型不一致：比如目标表
id是BIGINT，临时表用INT，触发隐式转换，索引失效 - 依赖自动推导：用
AS SELECT创建时，SUM(amount) AS total这类表达式会让字段名带括号或函数痕迹，后续ON或WHERE引用困难
必须显式建表 + 显式索引
别图省事用 CREATE TEMPORARY TABLE AS SELECT。三步顺序不能乱：
-
CREATE TEMPORARY TABLE tmp_updates (id BIGINT PRIMARY KEY, new_status TINYINT NOT NULL)—— 类型与目标表严格对齐，主键即索引 -
INSERT INTO tmp_updates VALUES (123, 1), (456, 2), ...—— 单批 ≤ 1000 行，防max_allowed_packet超限 -
UPDATE orders o INNER JOIN tmp_updates t ON o.id = t.id SET o.status = t.new_status—— 必须INNER JOIN，且确保orders.id本身也有索引
连接池环境下不 DROP 就会炸
临时表生命周期绑定物理连接，不是事务、不是会话逻辑块：
- ORM（如 Django/SQLAlchemy）复用连接时，若上一次没
DROP TEMPORARY TABLE IF EXISTS tmp_updates，下次执行直接报Table 'tmp_updates' already exists - 多线程共用一个连接（某些老配置），两个线程同时建同名临时表，必然冲突
-
DROP TEMPORARY TABLE不是可选项，是必选项；加IF EXISTS避免因异常跳过导致后续失败
临时表不是万能解药，得看场景
以下情况强行上临时表，只会让问题更复杂：
- 更新条件是模糊匹配，例如
WHERE name LIKE '%abc%'—— 临时表无法建立高效关联字段 - 数据源来自分页 API 流式返回，无法一次性拿到全部 ID —— 改用
WHERE id BETWEEN ? AND ?分片更稳 - 目标表关联字段是
TEXT且建索引代价过高 —— 此时应优先考虑重构字段或改用应用层聚合 - 单次更新量小于 100 行 —— 子查询更轻量，临时表的创建/销毁开销反而占主导
真正难的从来不是语法，而是每次执行前你是否估算过：这临时表会进内存还是落磁盘？索引建在哪个字段才真正被用上？连接会不会被复用？这些细节一漏，性能就断崖下跌。
