批量加载时将大型参考表转为临时表是否存在优势？

临时表的实际优势 #

先给个明确说法：把参考表转成临时表确实能带来实打实的好处，但核心是否能驻留内存，得看你用的数据库配置和临时表的存储引擎：

• 避免重复磁盘IO：如果是多批次加载，普通参考表每次关联都可能从磁盘读数据（就算有缓存，也可能被其他操作挤出去），但如果把临时表配置成内存存储，就能一直留在内存里，全程绕开昂贵的磁盘读取，速度提升很明显。
• 减少锁冲突：原参考表可能有业务读写，临时表是会话或事务级别的，批量加载时不会和其他业务抢原表的锁，能让整个流程更稳定。
• 针对性优化性能：可以给临时表只建关联需要的索引，甚至只保留关联必需的字段（砍掉原表的冗余字段），这样不管是加载还是关联，速度都能更快。

但要注意：临时表生命周期有限，比如会话结束就没了，如果是跨会话的批量加载，每次都得重新创建，这时候就得权衡重建的开销和重复读磁盘的开销哪个更大。

3GB内存级参考表的批量加载最佳实践 #

针对这种能塞进内存的大表，给几个实用的操作建议：

• 用内存优化的临时表：不同数据库有不同玩法：
  • MySQL：直接建CREATE TEMPORARY TABLE ... ENGINE=MEMORY，记得提前调大max_heap_table_size参数，确保能装下3GB数据。
  • PostgreSQL：先调temp_buffers参数，建完临时表后跑个ANALYZE，让优化器生成最优的执行计划。
  • SQL Server：用内存优化表（Memory-Optimized Tables），配置好足够的内存配额。
• 预加载一次复用多批：如果批量加载是在同一个会话里的多批次操作，一次性把参考表数据导入临时表，后面的批次直接用就行，别每次都重新加载。
• 精简数据：只留批量关联必须的字段，比如关联键和要获取的目标字段，多余的字段全删掉，既能省内存，又能加快数据加载和关联的速度。
• 只建必要的索引：别给临时表建一堆没用的索引，只建关联时用到的字段的索引就行，不然加载数据的时候还要维护索引，反而拖慢速度。
• 盯紧内存使用：确保数据库有足够内存装下这3GB临时表，别内存不够导致临时表溢出到磁盘，那反而不如直接用原表了。可以通过数据库自带的系统视图监控内存占用，比如MySQL的information_schema.tables，PostgreSQL的pg_stat_user_tables。
• 提前考虑扩容：如果以后参考表会变大到装不下内存，可以提前按关联键分区，批量加载时只把需要的分区导入临时表，减少内存压力。

内容的提问来源于stack exchange，提问作者SeaChange