临时表需显式建结构并加索引，避免类型失控和全表扫描；UPDATE JOIN 临时表比子查询快一个数量级；其生命周期绑定会话而非事务，须显式DROP防重名失败。
临时表在存储过程里必须显式创建结构
直接用 CREATE TEMPORARY TABLE ... AS SELECT 在存储过程中容易踩坑：MySQL 5.7+ 虽支持，但若 SELECT 中含函数（如 DATE()、CONCAT()）或表达式，列类型会变成 VARBINARY，后续 JOIN 或 WHERE 可能因隐式转换失败。更稳妥的做法是先定义结构，再插入数据。
- 显式建表：
CREATE TEMPORARY TABLE temp_user_stats (user_id INT PRIMARY KEY, total_spent DECIMAL(12,2)) - 再填充：
INSERT INTO temp_user_stats SELECT user_id, SUM(amount) FROM orders WHERE ... GROUP BY user_id - 避免字段类型失控，尤其当后续要和主表
INT字段JOIN时
索引不能省，否则临时表等于白建
临时表默认无索引，而存储过程中常需多次引用（比如先过滤、再关联、再聚合），没索引的临时表在十万行以上就会明显退化为全表扫描。MySQL 不会自动为 AS SELECT 生成的临时表加索引，必须手动补。
- 建完表后立刻加索引：
CREATE INDEX idx_temp_uid ON temp_user_stats (user_id) - 若用于
JOIN，索引字段顺序要匹配连接条件；若用于WHERE ... ORDER BY，考虑联合索引 - 注意：MySQL 5.6 对临时表索引支持较弱，5.7+ 和 8.0 更稳定
UPDATE JOIN 临时表比子查询快一个数量级
存储过程里常见“根据某规则更新一批记录”，若用子查询写法：UPDATE users SET status = 'done' WHERE id IN (SELECT id FROM orders WHERE ...)，MySQL 每行都重跑子查询。换成临时表 + JOIN，执行计划从 DEPENDENT SUBQUERY 变成哈希连接，实测百万级数据可从 30s 降到 2s 内。
- 正确写法：
UPDATE users u JOIN temp_update_ids t ON u.id = t.id SET u.status = 'done' - 错误写法：
UPDATE users SET status = 'done' WHERE id IN (SELECT id FROM temp_update_ids)—— 这仍触发嵌套循环 - MySQL 8.0+ 对
UPDATE ... JOIN优化更好；5.7 也支持，但避免在事务中跨语句复用同一临时表名（会报Table 'xxx' already exists）
临时表生命周期绑定会话，不是事务
这是最常被忽略的一点：存储过程里建的临时表，在该会话内一直存在，哪怕事务已 COMMIT 或 ROLLBACK。如果同一个存储过程被反复调用，不显式 DROP TEMPORARY TABLE，第二次执行会因表已存在而失败。
- 务必在存储过程末尾加：
DROP TEMPORARY TABLE IF EXISTS temp_update_ids - 不要依赖“会话断开自动删”——存储过程常被复用在长连接池中，连接不会频繁断开
- 命名建议带上下文前缀，如
temp_proc_order_batch_202609，避免同会话下多个过程冲突
