Lock类等待是生产环境慢查询和卡顿的头号元凶，表现为state=’active’却无响应；LWLock、BufferPin及wait_event为空分别指向系统资源争用、缓存热区争用和CPU密集型计算。
Lock 类等待：最常见也最危险的阻塞源头
wait_event_type = 'Lock' 出现时，说明进程正在等待获取一个重量级锁（比如表锁、行锁、事务ID锁），这是生产环境慢查询和卡顿的头号元凶。它不像 idle in transaction 那样容易被肉眼识别，而是“静默阻塞”——前端超时、应用日志报错，但数据库里只看到一个 state = 'active' 却迟迟不返回的查询。
常见场景包括：
-
UPDATE或DELETE未提交事务长期持有行锁，导致后续查询在relation或tuple上等待 - DDL 操作（如
ALTER TABLE）需要AccessExclusiveLock，而此时有长事务正读取该表 - 应用端开启事务后忘记
COMMIT或ROLLBACK，造成idle in transaction状态下仍持锁
注意：wait_event 字段显示具体锁类型（如 relation、transactionid、tuple），比只看 state 更能定位冲突对象。别只查 pg_stat_activity，配合 pg_locks 查谁在持锁、谁在等锁才是闭环。
LWLock 类等待：系统级资源争用信号
wait_event_type = 'LWLock' 表示进程在等轻量级锁（Lightweight Lock），这类锁用于保护共享内存中的关键结构，比如 WAL 缓冲区、事务状态（CLog）、缓冲区描述符等。它本身不直接对应业务 SQL，但高频出现往往意味着底层压力已到临界点。
典型 wait_event 值及含义：
-
WALWriteLock：WAL 日志写入慢，可能是磁盘 I/O 瓶颈或 checkpoint 频率过低 -
ProcArrayLock：大量并发事务竞争活跃事务列表，常见于高并发短事务场景（如秒杀） -
BufferMappingLock：热点数据页频繁被多个 backend 同时查找，常伴随缓存命中率下降
⚠️ 容易踩的坑：看到 LWLock 就去调大 shared_buffers 或 wal_buffers，但若根本原因是 SQL 缺索引导致全表扫描刷脏页，加内存只会让问题更隐蔽。先确认是不是有异常查询在持续制造压力，再调参。
BufferPin 类等待：缓存热区争用的直接证据
wait_event_type = 'BufferPin' 意味着进程正等待对某个数据页 buffer 加 pin（即固定住不让被驱逐），本质是多个 backend 同时访问同一组热数据页。这不是锁，但效果类似——后到的进程必须等前一个释放 pin 才能继续。
