Neon Postgres Egress Optimizer 实用指南

在需要诊断和修复代码库中过多的 Postgres 出站（网络数据传输）时使用此技能。当用户提到高额数据库账单、意外的数据传输费用、网络传输收费、出站峰值、“为什么我的 Neon 账单这么高”、“数据库成本激增”、SELECT * 优化、查询等情况时使用。

指导用户诊断和修复导致其 Postgres 数据库产生过多数据传输（出站）的应用程序端查询模式。大多数高出站费用是由应用程序获取的数据超过实际使用量造成的。

确定哪些查询传输的数据最多。主要工具是 pg_stat_statements 扩展。

SELECT 1 FROM pg_stat_statements LIMIT 1;

如果发生此错误，需要创建扩展：

CREATE EXTENSION IF NOT EXISTS pg_stat_statements;

在 Neon 上，它默认可用，但可能需要执行这个 CREATE EXTENSION 步骤。

当 Neon 计算实例缩放到零并重新启动时，统计数据会被清除。如果统计数据为空或计算实例刚刚唤醒：

如果用户拥有来自生产数据库的统计数据，请使用这些数据。如果他们无法访问生产统计数据，请继续执行步骤2，直接分析代码库——代码级模式通常足以识别最严重的问题。

运行这些以识别主要的出口贡献者。重点关注返回大量行、返回宽行（JSONB、TEXT、BYTEA 列）或调用频率很高的查询。

SELECT query, calls, rows AS total_rows, rows / calls AS avg_rows_per_call
FROM pg_stat_statements
WHERE calls > 0
ORDER BY rows DESC
LIMIT 10;

每次执行返回最多行的查询（范围不明确的 SELECT、缺少分页）：

SELECT query, calls, rows AS total_rows, rows / calls AS avg_rows_per_call
FROM pg_stat_statements
WHERE calls > 0
ORDER BY avg_rows_per_call DESC
LIMIT 10;

最常被调用的查询（适合缓存的候选项）：

SELECT query, calls, rows AS total_rows, rows / calls AS avg_rows_per_call
FROM pg_stat_statements
WHERE calls > 0
ORDER BY calls DESC
LIMIT 10;

运行时间最长的查询（不是直接的出口流量指标，但有助于在激增期间识别问题查询）：

SELECT query, calls, rows AS total_rows,
  round(total_exec_time::numeric, 2) AS total_exec_time_ms
FROM pg_stat_statements
WHERE calls > 0
ORDER BY total_exec_time DESC
LIMIT 10;

按估计退出影响对结果进行排名：

对于步骤 1 中识别的每个查询，或者如果没有可用统计信息，则对代码库中的每个数据库查询，检查：

对发现的每个问题应用适当的修复方法。以下是最常见的出口反模式及其修复方法。

问题: 查询获取了所有列，但应用程序只使用其中的几列。大的列（JSONB 块，TEXT 字段）会被传输过网络然后被丢弃。

SELECT id, name, price, image_urls FROM products;

问题： 列表端点返回所有行，没有限制 (LIMIT)。这是一个无限制的数据外泄风险 —— 表中的每一行新增都会增加每次请求的数据传输量。无论当前表的大小如何，都要标记此问题。

这很容易被忽视，因为该应用在小数据集下可能运行良好。但在大规模情况下，一个未分页的端点返回1万行数据，即使列宽适中，也可能每天传输数百兆字节的数据。

SELECT id, name, price FROM products
ORDER BY id
LIMIT 50 OFFSET 0;

在添加分页时，检查使用的客户端是否已经支持分页响应。如果没有，请选择合理的默认值，并在 API 中记录分页参数。

问题: 一个查询每天被调用数千次，但返回的数据很少改变。每次调用都会从数据库传输相同的行。这个模式只能从 pg_stat_statements 中看到——代码本身看起来很正常。

查找与其他查询相比调用次数极高的查询。常见示例：配置表、类别列表、功能标志、用户角色定义。

修复： 在应用程序和数据库之间添加缓存层，以避免每次请求都访问数据库。

问题： 该应用程序从表中获取所有行，然后在应用程序代码中计算聚合（平均值、计数、求和、分组）。即使结果只是一个小的摘要，整个数据集仍然通过网络传输。

之前： 应用程序获取整个表，并在代码中使用循环或 .reduce() 进行聚合。

SELECT p.category_id,
       AVG(r.rating) AS avg_rating,
       COUNT(r.id) AS review_count
FROM reviews r
INNER JOIN products p ON r.product_id = p.id
GROUP BY p.category_id;

问题: 宽父表和子表之间的 JOIN 会在每个子行上重复所有父列。如果一个产品有 200 条评价，并且产品行包含一个 50KB 的 JSONB 列，则该 join 对单个请求会发送 50KB × 200 = 约 10MB 的数据。

这与 SELECT * 问题不同。即使你只选择所需的列，JOIN 仍会为每个子行重复父数据。解决方法是结构性的：完全避免使用 JOIN。

SELECT * FROM products
LEFT JOIN reviews ON reviews.product_id = products.id
WHERE products.id = 1;

SELECT id, name, price, description, image_urls FROM products WHERE id = 1;
SELECT id, user_name, rating, body FROM reviews WHERE product_id = 1;

两个查询而不是一个 JOIN。产品数据只获取一次。评论只获取一次。没有重复。

上面的修复减少了出站流量（从 Postgres 传出的数据）。另一个大的非生产成本杠杆是计算，你可以在 neon.ts 中持久化地进行编码——Neon 的基础设施即代码文件（完整参考请参见 neon 技能）——这样开发、预览和 CI 分支默认保持低成本，而不依赖于每个分支的标志：

// neon.ts
import { defineConfig } from "@neon/config/v1";

export default defineConfig({
  branch: (branch) => {
    if (branch.exists || branch.isDefault) return {}; // don't touch prod
    return {
      ttl: "7d", // ephemeral branches auto-expire instead of accruing storage
      postgres: {
        computeSettings: {
          autoscalingLimitMinCu: 0.25, // scale to zero when idle
          autoscalingLimitMaxCu: 1, // cap autoscaling on throwaway branches
          suspendTimeout: "5m",
        },
      },
    };
  },
});

neon config apply   # apply to the current branch (neon deploy is an alias)

这是互补的，而不是替代的：查询模式修复实际上是降低出口费用的方式，而这些设置则防止非生产计算和存储默默增加同一账单。因为 neon checkout 在创建分支时会应用该策略，所以新的开发/预览分支会自动继承这个低成本配置。

来源说明：本文内容整理自开源项目 agentic-awesome-skills（中文翻译版），遵循 CC BY 4.0（知识共享署名 4.0 国际）许可协议，此处作为中文资料整理分享，版权归原作者所有。

Diagnose and fix excessive Postgres egress (network data transfer) in a codebase. Use when a user mentions high database bills, unexpected data transfer costs, network transfer charges, egress spikes, "why is my Neon bill so high", "database costs jumped", SELECT * optimization, query...

人工智能

Neon Postgres Egress Optimizer提供诊断与修复数据库过度出站传输的完整方案，涵盖pg_stat_statements查询分析、代码库检查及修复策略，有效降低Neon账单成本，助力高额数据传输问题解决。

基础设施即代码

数据结构

数据库

Agent

文章

问答

视频

教程

学习中心

腾讯云实验室

直播

竞赛

腾讯云代码分析专区

腾讯iOA零信任安全管理系统专区

腾讯云架构师技术同盟交流圈

腾讯云数据库专区

腾讯云智能顾问专区

腾讯云原生专区

腾讯混元专区

腾讯云TCE专区

腾讯云Lighthouse专区

腾讯云HAI专区

腾讯云Edgeone专区

腾讯云存储专区

腾讯云智能专区

腾讯轻联专区 

腾讯云开发专区

TAPD专区

腾讯轻量云游戏服专区

EdgeOne AI 安全实战专区

腾讯云最具价值专家

腾讯云架构师技术同盟

腾讯云创作之星

腾讯云开发者先锋

腾讯云代码助手

云原生构建

TAPD 敏捷项目管理

Cloud Studio

SDK中心

API中心

命令行工具

涵盖代码开发、场景应用、自动测试全流程，助你从零构建专属AI助手

一站式MCP教程库，解锁AI应用新玩法

聚焦“写作效率、视觉美观与运行性能”三方面进行全面升级，为您提供更高效、稳定的创作环境

社区富文本&Markdown编辑器全新改版上线，欢迎大家体验!

诚挚邀请您参与本次调研，分享您的真实使用感受与建议。您的反馈至关重要，感谢您的支持与参与！

Neon Postgres Egress Optimizer 实用指南

Neon Postgres Egress Optimizer 实用指南

社区

活动

圈层

关于

腾讯云开发者

热门产品

热门推荐

更多推荐