在GCP Cloud Run应用中安全更新80万条PGSQL记录的最优方案

针对80万条记录的更新需求，又不能停服，核心是把大更新拆成小批次，尽可能缩短锁的持有时间，避免阻塞用户请求。以下是具体实操方法：

1. 强制分批更新（必做） #

绝对不要用单条UPDATE语句扫全表更新，直接拆成每次1000-5000条的小批次（具体数量可以先测500、1000，看数据库负载调整），循环执行直到完成。
用主键或者唯一有序字段（比如id）来划分批次，避免重复处理或漏更：

WITH batch AS (
  SELECT id FROM your_table 
  WHERE 你的更新条件 AND 可选：未更新标记（比如is_updated = false）
  ORDER BY id LIMIT 1000
)
UPDATE your_table t
SET target_column = new_value, is_updated = true
FROM batch b
WHERE t.id = b.id;

每批执行完后休眠0.1-0.5秒，给数据库腾出手处理用户的正常请求，避免CPU/IO被更新占满。

2. 最小化锁的影响 #

• 上面的分批方式只会锁定当前批次的行，不会触发全表锁，这是关键。
• 确保WHERE子句里的筛选字段有索引，比如给更新条件里用到的字段、id字段建索引，减少查询时间，锁持有时间自然就短了。
• 尽量选用户访问量最低的时段执行，比如凌晨，哪怕不能完全避开高峰，也能降低冲突概率。

3. 监控与兜底措施 #

• 实时盯数据库状态：用SELECT * FROM pg_locks看锁的情况，SELECT * FROM pg_stat_activity看当前运行的查询，一旦发现大量等待锁的请求，立刻暂停更新。
• 可以临时调高数据库的CPU/内存配额（如果有预算），但别调太猛，避免影响Cloud Run实例的资源分配。
• 提前写好回滚脚本，如果更新导致用户请求超时、错误率飙升，立刻停更，先恢复服务，再调整批次大小或者换时段执行。

4. 复杂更新的优化技巧 #

如果更新逻辑需要计算（比如基于其他字段生成新值），可以先把计算结果存进临时表，再分批更新，减少每批的计算开销：

-- 先把要更新的id和计算好的新值存临时表
CREATE TEMP TABLE update_temp AS
SELECT id, your_calculate_function(column) AS new_val
FROM your_table WHERE 你的更新条件;

-- 循环分批更新
WHILE EXISTS (SELECT 1 FROM update_temp) LOOP
  WITH batch AS (
    SELECT id, new_val FROM update_temp LIMIT 1000
  )
  UPDATE your_table t
  SET target_column = b.new_val
  FROM batch b
  WHERE t.id = b.id;

  -- 删掉已经处理完的数据，避免重复
  DELETE FROM update_temp WHERE id IN (SELECT id FROM batch);
  SELECT pg_sleep(0.1);
END LOOP;

如果表中有热点数据（比如经常被用户访问的行），可以先跳过这些数据，最后单独处理，避免锁冲突拖慢整个更新流程。

内容的提问来源于stack exchange，提问作者Debi