postgresql中需用now()-xact_start计算事务运行时长，重点排查state='idle in transaction'的长事务，并联查pg_locks定位锁等待链，避免误杀应优先使用pg_cancel_backend。
查 pg_stat_activity 看长事务的 backend_start 和 xact_start
PostgreSQL 没有“事务运行时长”直接字段，得靠时间差推算。重点看 xact_start（事务开始时间）和当前时间的差值，比 backend_start（连接建立时间）更准——因为一个连接可能空闲很久才开启事务。
实操建议：
- 用
now() - xact_start计算持续秒数，过滤掉xact_start IS NULL（即未在事务中）的行 -
state = 'active'不能代表事务长，只表示后端正在执行某条语句；真正要抓的是state = 'idle in transaction'且持续很久的会话——这往往是应用没提交/回滚导致的悬挂事务 - 加
ORDER BY xact_start降序，一眼看到最老的事务
SELECT pid, usename, datname, client_addr,
now() - xact_start AS xact_duration,
state, query
FROM pg_stat_activity
WHERE xact_start IS NOT NULL
AND now() - xact_start > interval '5 minutes'
ORDER BY xact_start;
联查 pg_locks 判断谁在等什么锁、谁持有锁
单看 pg_stat_activity 只知道“有长事务”，但不知道它卡在哪。必须关联 pg_locks 才能定位锁等待链：谁在等锁（granted = false），谁持有锁（granted = true），锁类型（locktype）和对象（relation、page、tuple 等）。
关键点：
-
pg_locks.pid对应pg_stat_activity.pid，这是关联依据 -
mode字段显示锁级别，如RowExclusiveLock、ShareLock、AccessExclusiveLock；其中AccessExclusiveLock最重，通常阻塞所有其他操作 - 若
granted = false且存在同locktype+database+relation的granted = true记录，就构成明确等待关系
SELECT blocked_locks.pid AS blocked_pid,
blocked_activity.usename AS blocked_user,
blocking_locks.pid AS blocking_pid,
blocking_activity.usename AS blocking_user,
blocked_activity.query AS blocked_query,
blocking_activity.query AS current_statement_in_blocking_process,
blocked_locks.mode AS blocked_mode,
blocking_locks.mode AS blocking_mode
FROM pg_catalog.pg_locks blocked_locks
JOIN pg_catalog.pg_stat_activity blocked_activity ON blocked_activity.pid = blocked_locks.pid
JOIN pg_catalog.pg_locks blocking_locks
ON blocking_activity.pid = blocking_locks.pid
JOIN pg_catalog.pg_stat_activity blocking_activity ON blocking_activity.pid = blocking_locks.pid
WHERE NOT blocked_locks.granted
AND blocking_locks.granted;
识别常见危险锁类型和对应场景
不是所有锁都危险，但某些组合极易引发级联阻塞。重点关注：
-
AccessExclusiveLock：DDL（如ALTER TABLE、DROP INDEX）或TRUNCATE持有，会阻塞所有并发读写；一旦被长事务持有，整个表基本不可用 -
RowExclusiveLock+tuple级别锁：通常来自UPDATE/DELETE语句，若事务未结束，该行持续被锁，其他会话更新同一行就会卡住 -
ShareLock或ShareRowExclusiveLock：常见于CREATE INDEX CONCURRENTLY建索引期间，若建索引被长事务拖住，会一直等待AccessShareLock释放
注意：locktype = 'virtualxid' 或 'transactionid' 属于内部事务 ID 锁，一般不直接导致业务阻塞，可先忽略。
避免误杀：kill 前先确认事务是否真可中断
pg_terminate_backend(pid) 能强行断开连接，但风险不小：
- 若事务正在执行大事务（如大批量
UPDATE），中断可能导致部分数据已改、部分未改，应用层无感知，产生数据不一致 - 某些客户端（如 JDBC）默认启用
autosave=conservative，kill 后重连可能自动重放未完成语句，造成重复执行 - 优先尝试
SELECT pg_cancel_backend(pid)发送取消信号——它只中断当前查询，不杀连接，事务仍保持idle in transaction状态，留给应用自行处理
真正需要 pg_terminate_backend 的，通常是 idle in transaction 超过 30 分钟、且确认应用无响应的悬挂事务。
