PostgreSQL批量UPDATE应先评估是否真需分批，强聚集性数据单次更新更高效；必须用WHERE+LIMIT分批，以主键为游标推进，避免OFFSET，索引WHERE字段，应用层控制事务和重试。
UPDATE 太慢或锁表？先确认是否真需要批量
PostgreSQL 的 UPDATE 默认是事务级原子操作，单条语句更新百万行不会自动分批——它会一次性加锁、写 WAL、触发索引更新，极易导致长事务、锁等待甚至 OOM。但不是所有场景都该拆批：如果目标行集本身有强聚集性（比如按 created_at 索引顺序更新且数据物理连续），单次大更新反而比多次小更新更高效。先用 EXPLAIN ANALYZE 看执行计划里是否有 Seq Scan 或高成本 Sort，再决定是否分批。
用 WHERE + LIMIT 分批更新最可靠
PostgreSQL 不支持 UPDATE ... LIMIT 直接语法（9.5+ 的 UPDATE ... FROM ... LIMIT 仅限子查询上下文），必须靠循环控制。核心思路是：每次用 WHERE 定位一个子集，LIMIT 控制数量，靠主键或唯一有序字段推进游标。
- 推荐以主键（如
id）为分片依据：UPDATE orders SET status = 'shipped' WHERE id IN (SELECT id FROM orders WHERE status = 'pending' ORDER BY id LIMIT 1000);
- 执行后记录本次最大
id，下次查WHERE id > last_max_id AND status = 'pending' LIMIT 1000 - 避免用
OFFSET：越往后偏移，性能越差，因为每次都要跳过前面所有行 - 确保
WHERE条件字段有索引，否则每次扫描全表
在应用层控制提交频率比在 SQL 里更灵活
把分批逻辑交给应用代码，能精确控制事务边界、重试策略和监控粒度。例如 Python + psycopg2：
for batch in range(0, total_rows, 1000):<br> with conn.cursor() as cur:<br> cur.execute(<br> "UPDATE accounts SET balance = balance - %s WHERE user_id IN %s",<br> (amount, tuple(user_ids[batch:batch+1000]))<br> )<br> conn.commit() # 每批 commit 一次
- 每批执行后显式调用
conn.commit()，避免累积 WAL 日志 - 设置
conn.autocommit = False（默认），否则每个execute都自动提交，失去控制权 - 注意连接池行为：某些池（如 pgBouncer 的 transaction 模式）可能干扰手动 commit
- 若需失败后继续，捕获
psycopg2.errors.SerializationFailure并重试当前批次
不要依赖 pg_cron 或 pg_background_worker 自动跑批量 UPDATE
这些扩展适合定时任务，但不适合“控制提交频率”这种强状态依赖的操作。问题在于：
-
pg_cron任务是独立进程，无法感知上一批是否成功、最后处理到哪一行 -
pg_background_worker虽能持久运行，但调试困难、日志分散、升级易中断 - 它们都不提供批次间 pause、动态调整
LIMIT、或根据系统负载降速的能力 - 真正需要自动化时，用外部调度器（如 systemd timer、Airflow）调用带参数的脚本更可控
分批的核心其实是状态管理——哪批跑过了、哪批卡住了、当前系统负载如何，这些都得由你自己的逻辑判断，数据库本身不替你记账。
