用途：引导用户诊断并修复应用侧查询模式导致的 Postgres 出口流量（egress）过高问题。多数高额账单源于应用取回了超出实际使用的数据。
主要能力：
- 诊断：借助 pg_stat_statements 扩展定位传输数据最多的查询。先检查扩展是否可用：SELECT 1 FROM pg_stat_statements LIMIT 1; 若报错则执行 CREATE EXTENSION IF NOT EXISTS pg_stat_statements;。Neon 上默认可用，但可能仍需该步骤。统计在计算节点缩容到零并重启时会被清空，若为空可执行 SELECT pg_stat_statements_reset(); 后让应用在代表性流量下运行至少一小时再测。诊断查询覆盖：返回总行数最多、每次执行返回行数最多、调用最频繁、运行时间最长的查询。
- 代码分析：检查查询是否只选取所需列、是否限制返回行数（LIMIT/分页）、是否高频到值得缓存、是否在应用层做聚合、是否因 JOIN 重复父表数据。
- 修复常见反模式：SELECT * 改为显式列；无分页列表加 LIMIT/OFFSET；静态数据高频查询加缓存层；应用侧聚合下推到 SQL；宽父表与子表 JOIN 导致数据重复时改为两次独立查询。
- 验证：跑测试、确认 API 返回结构不变、重置统计后对比优化前后数据。
适用场景：数据库账单或数据传输费用异常升高、需要排查应用查询导致的出口流量问题。
限制：无生产统计时可退而分析代码库；分页与列裁剪可能破坏依赖完整结果或特定字段的客户端，需同步调整并记录分页参数。参考文档：https://neon.com/docs/introduction/network-transfer.md 与 https://neon.com/docs/introduction/cost-optimization.md。