PostgreSQL idle in transaction 很多怎么查：只读聚合卡与连接池分流
下载经PostgreSQL 14—18隔离验证的单行只读聚合卡，区分active、idle、idle in transaction、执行中等待、连接余量与可见性状态。
先用不含SQL和会话身份的聚合快照确认现象，再核对应用事务边界、连接归还、连接池、系统资源和最近发布；不直接终止backend或修改参数。
适用对象
- SQL-PG-07已在PostgreSQL 14.20、15.18、16.14、17.10与18.4隔离环境验证。
- 公开卡只返回一行实例级聚合，不输出query、库名、用户名、应用名、地址、对象名或会话标识。
- idle in transaction数量是现象，不是事务泄漏、连接池故障或应用根因的直接证明。
- 取消或终止backend、改连接池、改参数、扩容和生产写入都必须单独评估与授权。
idle in transaction很多时，第一步查什么
先确认实例级会话分布和连接余量，再回到应用事务边界。
运行只读卡前先记录错误、发生时间、受影响动作和未受影响范围。运行后只保存单行聚合与执行时间，不收集客户SQL、账号、地址或连接串。
| 信号 | 首轮能说明 | 不能单独证明 | 下一证据 |
|---|---|---|---|
| active | 当前正在执行的客户端连接量 | 高CPU或慢SQL根因 | 等待、资源与指纹级受控证据 |
| idle | 当前空闲客户端连接量 | 连接可以安全终止 | 连接池最小/最大值与归还策略 |
| idle in transaction | 事务已开启但当前未执行 | 事务泄漏或某个应用有错 | 事务时长、请求时间线与发布记录 |
| 执行中等待 | active连接中存在等待事件 | 锁、IO或网络中的唯一根因 | 等待类型、锁链与主机资源 |
怎样区分连接池耗尽与数据库连接耗尽
连接池获取超时可能发生在数据库仍有余量时，数据库连接接近上限也可能由多个应用、后台作业或集群路由共同造成。需要把应用层、数据库层和系统层证据分开采集，再对齐同一时间窗。
应用—数据库—系统三层分流
- 01
01
应用层
核对池上限、获取超时、事务边界、归还路径和近期发布。
- 02
02
数据库层
运行SQL-PG-07，比较相邻单行聚合与连接余量。
- 03
03
系统层
核对进程、线程、内存、文件句柄与容器限制。
- 04
04
责任分流
应用问题、固定范围体检、多节点DMP评估分别进入不同路径。
- 05
05
动作授权
任何终止、参数、连接池、切换或扩容动作逐项批准并回读。
公开资料只形成证据和停止条件，不执行生产动作。
什么时候从自查进入B-HC或DMP评估
已有相邻快照但仍无法区分应用、数据库和系统因素时，可进入B-HC固定范围健康体检；只有涉及多节点角色、路由或容量联动时，才进入DMP能力评估。
| 证据状态 | 建议路径 | 交付 | 不包含 |
|---|---|---|---|
| 只有一次聚合 | 继续采集相邻快照 | 现象变化与时间窗 | 根因或修复结论 |
| 多层证据冲突 | B-HC固定范围健康体检 | 风险Top 5、证据缺口、整改顺序 | 自动改生产 |
| 多节点与路由联动 | DMP集群管控评估 | 拓扑、能力和实施前置条件 | 自动部署或切换 |
| 生产需要立即动作 | 单独授权应急评估 | 动作范围、回退和回读 | 未授权终止或变更 |
参考依据
以下来源用于确认市场趋势、政策背景和术语边界；具体落地方案仍以客户的数据范围、权限和交付目标为准。
常见问题
idle in transaction达到多少就必须处理？
没有适用于所有系统的固定数量。要结合持续时间、连接余量、业务影响、事务边界、连接池和历史基线判断。
可以按这张卡直接终止会话吗？
不可以。卡片不输出会话身份，也不评估事务回滚成本、所有者和业务影响；取消或终止backend必须单独授权。
缺少pg_read_all_stats怎么办？
卡片返回insufficient_visibility。不要为公开自查临时扩大权限，应由数据库负责人决定受控观察账号和执行窗口。