答案：PostgreSQL临时表膨胀和临时空间使用过多主要由频繁创建临时表或复杂查询导致，优化策略包括监控temp_files和temp_bytes指标，调整work_mem减少落盘，避免冗余排序与哈希连接，将临时表空间移至高速磁盘，合理使用UNLOGGED表替代临时表，并控制CTE物化行为，从而降低I/O压力并提升性能。
PostgreSQL中的临时表膨胀和临时空间使用过多，通常出现在大量使用CREATE TEMPORARY TABLE或执行复杂查询（如排序、哈希连接）导致频繁写入临时文件的场景。这类问题会影响性能，甚至耗尽磁盘空间。以下是针对临时表膨胀与临时空间使用的优化策略。
理解临时表与临时空间的机制
PostgreSQL在以下情况会使用临时对象：
- 显式创建的临时表（
TEMPORARY TABLE），仅在当前会话可见，会话结束自动清理。 - 内部操作生成的临时文件，用于大结果集排序、哈希表构建、物化CTE等。
这些临时数据默认存储在temp_tablespaces指定的目录中，若未设置，则使用数据目录下的base/pgsql_tmp路径。
注意：临时表本身不会“膨胀”像普通表那样产生大量死元组，但频繁创建/删除临时表可能造成目录碎片或元数据压力；真正的“膨胀”更多体现为临时文件占用大量磁盘空间。
监控临时空间使用情况
定期检查临时文件的生成量，有助于发现异常行为。
查看每个数据库的临时文件使用统计：SELECT datname, temp_files, temp_bytes FROM pg_stat_database WHERE temp_files > 0;
该查询显示每个数据库产生的临时文件数量和总大小。如果某数据库的temp_bytes持续增长，说明其查询可能频繁落盘处理中间结果。
查看当前正在运行并可能使用临时空间的查询：
SELECT pid, query, temp_files, temp_bytes FROM pg_stat_activity WHERE temp_files > 0;
结合执行计划分析这些查询是否可优化。
优化查询以减少临时文件生成
大多数临时空间消耗源于内存不足时，排序或哈希操作被迫写入磁盘。可通过以下方式优化：
-
增加work\_mem：提高每个排序或哈希操作可用的内存。例如：
SET work_mem = '64MB';
注意不要设得过高，避免整体内存超限。 - 避免不必要的ORDER BY或DISTINCT：尤其是对大结果集的操作，若上层无需有序，应去掉排序。
-
优化JOIN策略：强制使用嵌套循环或合并连接，避免大表哈希连接落盘，可通过
SET enable_hashjoin = off;测试（仅调试用）。 - 拆分大查询：将一次性处理百万行的CTE或子查询改为分批处理，减少中间结果集体积。
合理配置临时表空间
将临时文件放置在高性能、独立的磁盘上，可以减轻主数据目录的压力，并提升I/O效率。
创建专用临时表空间：CREATE TABLESPACE fast_temp LOCATION '/ssd/pg_temp';
设置会话或全局使用该表空间：
SET temp_tablespaces = 'fast_temp';
这样所有临时对象（包括临时表和临时文件）都会写入指定位置。确保目标路径有足够空间并具备良好读写性能。
也可以设置多个表空间实现负载均衡：
SET temp_tablespaces = 'fast_temp1, fast_temp2';
管理临时表生命周期与设计替代方案
虽然临时表在会话结束时自动清理，但长时间运行的会话中保留大量临时表仍会占用资源。
-
尽早删除不再需要的临时表：
DROP TABLE IF EXISTS tmp_step1; -
考虑使用UNLOGGED表代替：若需跨会话共享临时数据或希望更好控制生命周期，可使用
UNLOGGED表，它不写WAL日志，速度快，但崩溃后数据丢失。 -
慎用MATERIALIZED CTE：CTE默认可能被物化到临时文件，特别是当引用多次时。若只需流式处理，可尝试关闭物化：
SET jit = off; -- 某些情况下JIT与物化交互不良
或重写为子查询。
基本上就这些。关键是通过监控定位高消耗查询，调优内存参数，合理分配存储路径，并从应用层面减少对大规模临时数据的依赖。不复杂但容易忽略。
