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 才能继续。
DMap GL地图JSAPI（dmapgl）开发指南。用于编写、审查、调试 DMap 地图 API 代码，涵盖地图初始化、覆盖物渲染、图层管理、事件处理、控件交互等任务。当用户提及 dmap、dmapgl、jsapi‑gl 或相关地图开发需求时自动触发。
它常出现在以下情况：
- 多个并发查询反复扫描同一张小表（如配置表、字典表）
- 索引扫描中回表访问同一堆页（例如二级索引指向的主键页高度集中）
-
VACUUM或后台 writer 正在清理/刷脏页，而查询恰好要读同一 page
判断是否真热：查 pg_stat_user_tables 中 heap_blks_read 与 heap_blks_hit 比值；如果 hit 率低于 95%，说明缓存没起效，BufferPin 可能只是表象，根源还是数据访问模式不合理或 shared_buffers 不足。
wait_event 为空？别急着排除 CPU 问题
当 wait_event_type 和 wait_event 都为 NULL，但 state = 'active' 且 duration 持续增长，这不代表“一切正常”。它只说明当前没有等待外部资源（IO、锁、buffer 等），进程正在纯 CPU 上执行。
这时候要怀疑：
- 复杂表达式计算（如嵌套 JSON 解析、正则反复匹配、大量
string_to_array+unnest） - 排序或哈希操作内存不足，触发落盘（
Sort/Hash在EXPLAIN ANALYZE中显示disk） - 查询计划选择了 Nested Loop 且内表无索引，导致笛卡尔积级循环
验证方式很简单：用 EXPLAIN (ANALYZE, BUFFERS) 看实际耗时分布，重点关注 Execution Time 和各节点的 Actual Total Time。如果大部分时间花在某一步计算上，wait_event 空就是合理现象——问题不在等待，而在算力本身。
复杂点在于：wait_event 是瞬时快照，不是全程记录。一个查询可能前 10 秒等锁、中间 2 秒算 CPU、最后 5 秒等 IO，你查到的只是那一刻的状态。所以单次查询 pg_stat_activity 得到的 wait_event，永远只是拼图的一小块。
