临时表需显式声明temporary、避免命名冲突、及时建索引、慎用批量insert、防范连接池复用导致的残留问题，且不参与binlog复制。
能直接用，但得注意权限、命名冲突和会话生命周期——临时表不是“随便建完就能跑”的万能缓存。
CREATE TEMPORARY TABLE 语法必须带 TEMPORARY 关键字
MySQL 不接受 CREATE TABLE #xxx 或 CREATE TABLE temp_xxx 这种省略关键字的写法。少了 TEMPORARY，就建出来一个永久表，后续可能污染线上环境或引发权限报错。
- 正确写法：
CREATE TEMPORARY TABLE temp_updates (id INT, status INT) - 错误写法：
CREATE TABLE temp_updates (...)（建的是永久表） - 如果已有同名普通表，
CREATE TEMPORARY TABLE仍可成功——临时表在当前会话中优先级更高，但容易让人误以为操作的是原表 - 建表时可指定引擎：
ENGINE=MEMORY适合小数据量高频读；ENGINE=InnoDB支持事务和大字段，但写入略慢
INSERT 数据量大时，别用 VALUES 逐条插
用 INSERT ... VALUES 批量插入几千行以上，SQL 字符串会急剧膨胀，可能触发 max_allowed_packet 限制，或让解析变慢。更稳的方式是走 SELECT ... INTO 或分批导入。
- 推荐方式一（从已有表抽数据）：
CREATE TEMPORARY TABLE temp_orders AS SELECT id, amount, status FROM orders WHERE created_at > '2026-07-01' - 推荐方式二（应用层分批）：每 1000 行执行一次
INSERT INTO temp_orders VALUES (...), (...), (...) - 避免把 5 万行数据拼成一条超长
VALUES语句——MySQL 解析耗时陡增，还容易被客户端或代理截断
UPDATE 关联临时表时，JOIN 条件必须有索引
临时表默认不带索引，一旦 JOIN 大表（比如百万级 users），没索引就会全表扫描，性能崩盘。别指望“反正临时表小”就忽略这点。
- 建表后立刻加索引：
ALTER TABLE temp_updates ADD INDEX idx_id (id) - 如果临时表是从
SELECT ... AS创建的，它不继承源表索引，必须手动补 - JOIN 时确保两边关联字段类型一致：
temp_updates.id是INT，而users.id是BIGINT？隐式转换会让索引失效 - 执行前用
EXPLAIN看一眼：EXPLAIN UPDATE users u JOIN temp_updates t ON u.id = t.id SET u.status = t.status
临时表在存储过程中使用要防会话复用陷阱
存储过程里建临时表，看似“每次调用都新建”，但实际依赖连接池行为。如果连接被复用，上一次调用留下的临时表还在，CREATE TEMPORARY TABLE 会报错 “Table 'xxx' already exists”。
- 安全写法：开头加
DROP TEMPORARY TABLE IF EXISTS temp_data - 别依赖“会话结束自动删”——连接池让会话不结束，临时表就一直挂着
- 临时表名别用固定名（如
temp_result），建议带时间戳或随机后缀：temp_result_20260811_abc123 - 临时表不记录 binlog，所以主从复制里看不到它的操作——这既是优势（减少日志压力），也是盲区（无法审计变更）
临时表真正省事的地方，是不用清理和权限预设；真正容易翻车的地方，是把它当普通表用，忘了它只活在当前连接里，且没索引就是慢。
