文章目录每日一句正能量1. 背景与问题2. 环境与数据3. 复现过程4. 方案实施5. 结果对比6. 风险与复盘每日一句正能量“日子很滚烫又暖又明亮。”像经过盛夏的叶子脉络里藏着光。最好的航行是既奋力划桨也欣赏两岸风光并欣然接受河流本身的走向。这就是“事事如意”的人生。1. 背景与问题某数据分析平台每天凌晨执行报表任务业务库CPU利用率不高但磁盘IO持续100%base/pgsql_tmp目录临时文件快速增长。日志中不断出现LOG: temporary file: path base/pgsql_tmp/...结合业务特点发现大量排序Sort和哈希聚合HashAggregate在内存不足时落盘导致临时文件暴增最终影响整批报表完成时间。2. 环境与数据PostgreSQL 16Linux 964GB 内存NVMe SSD报表数据约1.2亿行SQL示例SELECTregion,sum(amount)FROMordersGROUPBYregionORDERBYsum(amount)DESC;优化前参数work_mem 4MB log_temp_files 0 temp_file_limit -1执行计划优化前Sort Sort Method: external merge Disk: 1860MB HashAggregate Buffers: shared hit126534 Execution Time: 63.8 s监控数据显示指标优化前临时文件总量18.6GB报表执行时间63.8s磁盘利用率99%Sort落盘次数463. 复现过程开启log_temp_files0记录全部临时文件。使用EXPLAIN (ANALYZE,BUFFERS)查看 Sort Method。配合iostat、vmstat采集IO。调整work_mem分阶段压测4MB、16MB、64MB。实验发现随着work_mem增大Sort Method 由external merge转变为quicksort磁盘临时文件明显减少。4. 方案实施参数调整work_mem 64MB log_temp_files 10MB temp_file_limit 20GB同时优化SQL为分组字段建立统计信息。避免一次查询返回过大中间结果集。将复杂报表拆分为多个阶段执行。优化后执行计划Sort Sort Method: quicksort Memory: 28540kB HashAggregate Execution Time: 28.4 s5. 结果对比指标优化前优化后临时文件18.6GB1.3GB报表耗时63.8s28.4sSort落盘次数463磁盘利用率99%58%日志中临时文件记录显著减少IO曲线恢复平稳。需要注意的是work_mem是每个排序/哈希节点、每个并发会话都可能分配的内存因此不能简单无限增大。6. 风险与复盘风险work_mem设置过大会导致高并发时内存耗尽。仅提高参数而不优化SQL仍可能产生大量中间结果。未限制temp_file_limit时异常SQL可能占满磁盘。复盘建议优先通过log_temp_files精确定位产生临时文件的SQL。使用EXPLAIN (ANALYZE,BUFFERS)判断是否发生排序或哈希落盘。分阶段压测不同work_mem配置避免一次性调得过大。联合观察pg_stat_statements、系统IO、临时文件目录大小以及报表完成时间形成长期监控。本文通过日志定位、执行计划分析、work_mem实验及参数前后对比完整展示了临时文件暴增的定位与治理思路适用于报表分析和批量统计等典型场景。转载自https://blog.csdn.net/u014727709/article/details/164031654欢迎 点赞✍评论⭐收藏欢迎指正