长事务会阻塞操作、引发XID回卷、表膨胀和复制延迟，需通过pg_stat_activity识别并终止异常事务，结合超时设置与监控预防。
在 PostgreSQL 中，长事务（Long-running Transaction）是指持续时间较长的事务，可能因为业务逻辑、锁等待或程序异常未提交/回滚导致。这类事务会对数据库稳定性带来显著风险，需及时识别和处理。
一、长事务的风险说明
长事务对 PostgreSQL 系统的影响主要体现在以下几个方面：
- 阻塞其他事务：长时间持有行锁或表锁，导致其他会话无法修改相关数据，引发性能下降甚至超时。
- 膨胀事务ID（XID）：PostgreSQL 使用事务ID进行可见性判断。长事务会阻止系统清理旧的事务ID，可能导致事务ID回卷（wraparound），严重时将导致数据库自动关闭以防止数据损坏。
- 表膨胀（bloat）：由于 MVCC 机制，未提交事务的存在会使旧版本元组无法被 vacuum 清理，造成表和索引体积膨胀，影响查询性能。
- 复制延迟：在主从复制环境中，长事务可能导致从库重放 WAL 日志延迟，影响高可用能力。
- 连接资源占用：长期占用连接会消耗连接池资源，可能引发连接数耗尽问题。
二、如何识别长事务
可以通过以下 SQL 查询识别当前运行时间较长的事务：
SELECT
pid,
now() - xact_start AS duration,
query,
state,
datname,
usename,
wait_event_type,
wait_event
FROM pg_stat_activity
WHERE state != 'idle'
AND now() - xact_start > interval '5 minutes'
ORDER BY xact_start;
说明：
Session Reset
下载
安全地重置 OpenClaw agent sessions，支持备份、预览、恢复和批量操作。用于：1) 清理过期的 agent 会话上下文，2) 重置特定 agents 的 session，3) 批量重置六部/秘书 sessions，4) 查看和恢复历史备份。当用户需要"reset session"、"清理 se...
-
xact_start表示事务开始时间，通过与当前时间差值判断持续时间。 - 可根据实际需求调整时间阈值，如 5 分钟、10 分钟等。
- 关注
state为 active 或 idle in transaction 的会话，后者表示事务已启动但未结束。 -
wait_event可帮助判断是否因锁等待导致事务卡住。
补充：查看事务 ID 年龄，预防 XID 回卷：
SELECT datname, age(datfrozenxid) AS xid_age FROM pg_database ORDER BY xid_age DESC;
若 xid_age 接近 20 亿（即接近 2^31），则存在回卷风险，需立即处理。
三、长事务的处理方法
发现长事务后，应根据具体情况采取以下措施：
-
分析 SQL 内容：查看
query字段确认事务执行的具体操作，判断是业务正常流程还是逻辑缺陷。 - 联系应用负责人：如果是业务必需的长时间事务，评估是否可优化拆分或使用更细粒度的事务控制。
- 终止异常事务：对于无响应或明显异常的事务，可通过以下命令终止：
-- 终止会话（推荐优先使用） SELECT pg_terminate_backend(pid); <p>-- 仅取消查询（不结束事务） SELECT pg_cancel_backend(pid);</p>
- 优化自动清理配置：确保 autovacuum 配置合理，避免因 vacuum 延迟加剧膨胀问题。
- 设置事务超时限制：在全局或会话级别启用超时机制，防止事务无限期运行：
-- 设置单个会话最大事务时长（单位毫秒） SET idle_in_transaction_session_timeout = '10min'; SET statement_timeout = '30min';
建议在生产环境配置 idle_in_transaction_session_timeout，防止程序忘记提交事务。
四、预防长事务的最佳实践
- 应用程序中避免在事务中执行耗时操作（如网络请求、文件处理）。
- 使用连接池时启用事务级连接回收或监控空闲事务。
- 定期巡检
pg_stat_activity和事务年龄，建立告警机制。 - 编写脚本每日检查最长事务并通知负责人。
- 关键业务上线前进行事务边界评审，减少大事务使用。
基本上就这些。长事务看似不起眼，但累积影响严重，尤其在高并发或大数据量场景下容易引发雪崩效应。主动监控+合理配置+快速响应，是保障 PostgreSQL 稳定运行的关键。
