批量更新时应分批提交、按主键排序、避免全表扫描、使用读已提交隔离级别，并采用skip locked跳过竞争行，以减少锁冲突。
在PostgreSQL中进行批量更新时，锁冲突是常见性能瓶颈之一。当多条记录被频繁更新，尤其是涉及同一行或相邻数据页时，容易引发行锁、页锁甚至表级锁竞争，导致事务阻塞、响应变慢。合理设计更新策略能显著减少锁冲突，提升并发处理能力。
使用较小的批量更新代替大事务
一次性更新数万甚至更多记录会持有锁较长时间，增加其他事务等待概率。应将大更新拆分为多个小批次执行。
- 每次更新1000~5000条记录，通过
WHERE id BETWEEN X AND Y或游标分批处理 - 每批之间可加入短暂延迟（如0.1秒），缓解系统压力
- 提交后释放锁资源，降低长事务带来的锁累积风险
按主键顺序更新避免死锁
并发更新不同记录时，若更新顺序不一致，可能形成循环等待，引发死锁。统一按主键排序可有效规避。
- 在
UPDATE前先按主键排序获取待更新ID列表 - 多个并发任务也遵循相同顺序更新，减少锁竞争路径
- 例如：
SELECT id FROM table WHERE cond ORDER BY id，再逐个或分批更新
选择合适的隔离级别
默认的读已提交（Read Committed）允许非重复读，但能最大程度减少锁占用时间。除非业务要求，避免使用可串行化（Serializable）等高隔离级别。
- 高隔离级别会引入 predicate lock 和 SIREAD 锁，增加冲突概率
- 确认不需要严格一致性时，保持使用 Read Committed
- 必要时用应用层逻辑补偿，而非依赖数据库强隔离
优化索引与查询条件
更新操作若无法快速定位目标行，会导致全表扫描并加大量意向锁，加剧冲突。
- 确保
WHERE条件字段有合适索引，避免全表扫描 - 避免在更新条件中使用函数表达式，防止索引失效
- 定期分析表统计信息：
ANALYZE table_name;
考虑使用FOR UPDATE SKIP LOCKED跳过竞争行
适用于消息队列类场景，多个进程并发处理待更新任务。
- 结合
SELECT ... FOR UPDATE SKIP LOCKED LIMIT N安全获取未锁定记录 - 避免因个别行被锁而阻塞整个批量处理流程
- 典型用于后台任务消费、状态流转等异步更新场景
基本上就这些。关键是控制事务粒度、减少锁持有时间、提升查询效率，并根据业务模式调整并发策略。不复杂但容易忽略细节。
