PostgreSQL监控里看到连接长期显示idle in transaction，但CPU并不高。这表示客户端已经开启事务，目前却没有执行查询，事务仍保持打开。
它不是普通idle连接。 长时间未结束的事务可能妨碍清理旧行版本或持有锁，应该先找出哪个应用会话留下了事务。
从pg_stat_activity定位会话
用有足够监控权限的账号查看pg_stat_activity中的pid、usename、application_name、client_addr、xact_start、state_change和state。按state = 'idle in transaction'筛选并计算事务持续时间。
为什么空闲仍有影响
官方将此状态定义为位于事务中但当前未执行查询。未提交事务可能保留锁或阻碍VACUUM回收已经死亡的元组；具体影响需结合锁等待和事务持续时间判断。不要把所有空闲连接都当作同一故障。
优先回到应用查事务边界
检查应用是否执行了BEGIN后没有COMMIT或ROLLBACK、异常路径遗漏清理、连接池归还前没有结束事务。query列在非active状态下显示的是上一条查询，不能仅凭它断定当前正在执行该SQL。
何时终止会话及其代价
确认会话归属、业务影响和事务是否可重试后，必要时使用SELECT pg_terminate_backend(pid)结束指定后端。此操作会断开连接并使未提交事务回滚；不要根据一条状态批量杀掉所有连接。
设置超时作为兜底
idle_in_transaction_session_timeout可终止在开放事务中闲置超过设定时间的会话。先在非关键角色或测试环境验证阈值对长事务业务的影响；根本修复仍是让应用可靠提交或回滚。
云服务器上的变更建议
在VPS上复现或调整配置时，先隔离验证。萤光云与LightNode可按所需地域和资源规格选择；变更前保留可恢复的备份。
FAQ
问：statement_timeout能清理闲置事务吗？答：它针对语句执行时长；事务闲置应检查idle_in_transaction_session_timeout及应用事务边界。
温馨提示
温馨提示：对生产连接执行终止前，先联系应用负责人并保留会话信息，避免影响仍需完成的业务事务。
