PostgreSQL行级锁通过合理设计可减少冲突。首先理解UPDATE、DELETE和SELECT FOR UPDATE等语句会触发排他锁或共享锁，导致阻塞或死锁；其次优化事务设计，缩短事务长度，按主键顺序更新，避免高频更新热点行，并选用合适隔离级别；再者利用SELECT FOR UPDATE SKIP LOCKED实现任务队列跳锁，结合版本号使用乐观锁，批量操作时分片加锁以降低锁范围；最后通过pg_locks和pg_stat_activity视图监控锁状态，开启log_lock_waits和deadlock_timeout记录异常，从而有效控制锁竞争，提升并发性能。
PostgreSQL 中的行级锁能有效提升并发性能，但若使用不当仍可能导致锁冲突、阻塞甚至死锁。合理设计锁控制策略，可以显著减少行级锁的冲突，提高系统吞吐量。
理解行级锁的触发场景
PostgreSQL 在执行数据修改操作时会自动获取行级锁，常见于以下语句：
-
UPDATE：修改某行时对该行加排他锁（
FOR UPDATE） - DELETE：删除行前锁定目标行
- SELECT ... FOR UPDATE / FOR SHARE：显式加锁读取
当多个事务试图同时修改同一行时，后到的事务会被阻塞，形成锁等待。若涉及多表或复杂事务，容易引发连锁阻塞。
优化查询与事务设计以减少锁竞争
减少锁冲突的核心在于缩短锁持有时间并降低热点行访问频率。
- 缩短事务长度：尽快提交事务，避免在事务中执行耗时操作（如网络请求、复杂计算）
- 按主键顺序更新多行：若多个事务需更新相同的一组行，统一按主键排序可降低死锁概率
- 避免在高并发场景频繁更新同一行：例如计数器类字段，可通过引入缓存层或将操作拆分为异步批处理来缓解
-
使用合适的隔离级别：如将非关键业务从
REPEATABLE READ改为READ COMMITTED，减少不必要的快照锁定
利用显式锁控制和乐观锁机制
在某些场景下，可以通过主动控制锁行为来规避冲突。
-
使用
SELECT ... FOR UPDATE SKIP LOCKED：适用于任务队列等场景，跳过已被锁定的行，直接处理可用资源，避免等待 - 结合版本号实现乐观锁：不在读取时加锁，而在更新时检查版本字段是否变化，适合读多写少的场景
- 批量处理时分片加锁：将大范围更新拆分为小批次，降低单次锁持有范围和时间
监控与诊断锁问题
借助系统视图及时发现潜在冲突。
-
pg_locks：查看当前所有锁信息，关联
pg_stat_activity可定位阻塞源头 -
pg_stat_activity：识别长时间运行或处于
idle in transaction状态的会话 - 设置
log_lock_waits = on和deadlock_timeout，记录长时间锁等待和死锁事件
基本上就这些。通过合理设计事务逻辑、控制锁粒度并辅以监控手段，可以在保证数据一致性的前提下最大限度减少行级锁冲突。关键在于避免长时间持有锁，以及减少对同一资源的集中争用。
