PostgreSQL 报表金额翻倍：一对多关联放大聚合的定位与修复
订单明细增加退款展示后，报表的销售额突然变大。单独查订单金额正确，单独查退款也正确，只有合并查询对不上。此时先检查关联后的数据粒度：一张订单同时对应多条商品明细和多条退款时，两组明细会组合成多行，最后的 SUM 会把同一金额累计多次。 本文以 PostgreSQL 17 为语义基准，用一套可复现数据定位问题，再把查询改
Tag
#PostgreSQL
包含这个标签的文章。
PostgreSQL 排除查询突然返回零行：NOT IN 遇到 NULL 的定位与修复
场景：有待处理订单，补偿任务却扫不到 补偿任务从订单表里找出“尚未有成功回执”的订单。原先使用 NOT IN (SELECT order_id ...)，导入一条未关联订单的回执后，任务突然返回零行，接口没有报错，查询耗时也正常。 下面是隔离复现，不代表真实生产事故。SQL 按 PostgreSQL 17 编写，使用会
PostgreSQL 并发建索引失败留下 INVALID：从等待取证到在线修复
适用场景 本文适用于 PostgreSQL 13 及以上版本的生产库：为了避免普通 CREATE INDEX 长时间阻塞写入，运维或开发人员改用 CREATE INDEX CONCURRENTLY，但命令执行数十分钟后失败、被取消，或者发布系统超时退出。重新执行时又提示索引已存在，查询计划却仍然走顺序扫描。 本文重点处
PostgreSQL 插入新数据却主键冲突：从序列漂移到安全校准的排查实践
适用场景 本文适用于 PostgreSQL 表使用 serial、bigserial 或 identity 列生成主键，但执行正常 INSERT 时仍出现主键重复的场景。常见诱因包括数据迁移、手工补数据、COPY 导入、只恢复表数据却漏掉序列状态，或者在不同环境之间合并数据。 典型表结构如下： CREATE TABLE
PostgreSQL 表越删越大且查询变慢：从死元组取证到 autovacuum 治理
适用场景 本文适用于更新、删除频繁的订单、任务、消息、审计记录等 PostgreSQL 表。典型现象是：业务已经清理大量历史数据，但表文件没有缩小；索引扫描和备份越来越慢；监控中的磁盘使用持续上涨；执行 VACUUM 后空间仍未归还操作系统。 本文重点解决三个问题：如何确认膨胀来自死元组，为什么 autovacuum
PostgreSQL 连接池耗尽：从 idle in transaction 到事务边界治理
适用场景 应用运行一段时间后，新请求开始等待数据库连接，接口 P99 持续升高，最终出现连接池获取超时或 PostgreSQL too many connections。数据库 CPU、磁盘 I/O 和慢 SQL 指标却不高，重启应用后又能短暂恢复。 这类现象经常不是“连接池太小”，而是业务代码开启事务后没有及时提交或