临时表能救场是因为它将不可控的IN子查询物化为可管理的中间层，通过主键索引、批量插入、ANALYZE更新统计信息及合理JOIN策略，避免OOM和执行计划误判。
IN子查询大数据量直接崩，为什么临时表能救场
因为MySQL和PostgreSQL对IN (SELECT ...)的物化策略不可控：子查询结果可能全量加载进内存，一过百万行就OOM；而临时表由你完全掌控生命周期、索引和数据分布。关键不是“换了个写法”，而是把优化器甩不掉的包袱，变成你能主动管理的中间层。
CREATE TEMPORARY TABLE必须带PRIMARY KEY或明确索引
没索引的临时表和原IN列表没区别——JOIN时照样全表扫描。别信“临时表默认快”这种模糊说法。
-
CREATE TEMPORARY TABLE temp_ids (id BIGINT PRIMARY KEY)：主键自动建B+树索引，JOIN效率最高 - 如果ID来自字符串或复合条件，改用
UNIQUE KEY (id, type)并确保后续JOIN条件顺序一致 - 避免
ENGINE=MEMORY：它不支持BLOB/TEXT，且重启会丢数据；ENGINE=InnoDB更稳 - INSERT别用单条VALUES：批量插入1000行以上时，用
INSERT INTO temp_ids VALUES (1),(2),(3),...,(1000)，比1000次单条快5–10倍
JOIN替代IN时，DISTINCT和驱动顺序不能忽略
原WHERE id IN (SELECT id FROM ...)天然去重，但JOIN可能因一对多关系产生重复行——这会导致结果错、COUNT不准、甚至内存翻倍。
- 如果业务只要“是否存在”，用
SELECT DISTINCT u.* FROM users u JOIN temp_ids t ON u.id = t.id - 如果要保留明细（比如查用户+订单），去掉
DISTINCT，但得确认应用层是否能处理重复 - 执行前先跑
EXPLAIN FORMAT=TREE：看实际驱动表是不是temp_ids（小表）；若显示orders被驱动，说明优化器误判，加STRAIGHT_JOIN强制顺序反而危险，应优先检查temp_ids行数统计是否准确（ANALYZE TABLE temp_ids）
临时表数据插入后立即ANALYZE，否则优化器瞎猜
MySQL不会自动更新临时表的统计信息。刚INSERT完10万行，优化器仍按空表估算，可能选错执行计划——比如该走索引却选了全表扫描。
- 插入完成后立刻执行
ANALYZE TABLE temp_ids - PostgreSQL用
ANALYZE temp_ids，效果一样 - 云数据库（如阿里云RDS、腾讯云CDB）有些版本禁用
ANALYZE，此时改用OPTIMIZE TABLE temp_ids（仅InnoDB有效） - 别依赖
innodb_stats_auto_update=ON：它对临时表基本不生效
临时表不是银弹。当temp<em>ids</em>超过500万行，或需要频繁复用，就得考虑分区临时表或落地为普通带索引的staging*表——否则每次重建开销反超IN本身。
