临时表+UPDATE FROM比直接UPDATE更适合大批量更新，因其将计算新值与应用变更分离，减少MVCC开销、避免死元组、利用顺序I/O和高效连接；需建带主键的临时表、分批写入、确保索引匹配、控制事务粒度并检查执行计划。
为什么临时表比直接 UPDATE 更适合大批量更新
PostgreSQL 的 UPDATE 对每行都生成新版本（MVCC），同时写 WAL、更新所有索引、产生死元组——10 万行更新 ≈ 10 万次 INSERT + DELETE。而用临时表 + UPDATE ... FROM，本质是把“计算新值”和“应用变更”分离：先批量写入临时表（顺序 I/O，无锁竞争），再通过哈希/索引连接高效匹配目标行。实测在千万级表上，耗时常能从小时级降到分钟级。
临时表 + UPDATE FROM 的标准写法
核心是两步：建临时表载入新值，再用 FROM 关联更新。注意临时表必须有主键或唯一约束字段用于精确匹配：
CREATE TEMP TABLE tmp_update_data (
id BIGINT PRIMARY KEY,
status_code TEXT,
updated_at TIMESTAMPTZ
);
INSERT INTO tmp_update_data VALUES (123, 'PROCESSED', NOW()), (456, 'FAILED', NOW());
UPDATE orders o
SET status_code = t.status_code,
updated_at = t.updated_at
FROM tmp_update_data t
WHERE o.id = t.id;
-
tmp_update_data必须含能与主表关联的字段（如id），且该字段最好建索引（临时表默认不自动建） - 如果主表
id是主键，PostgreSQL 会自动用 Index Scan；否则需确保o.id = t.id走索引，否则退化为 Nested Loop + 全表扫描 - 避免在
WHERE中对o.id做函数操作，例如WHERE o.id::TEXT = t.id会强制索引失效
分批写入临时表，防止内存溢出
一次性插入几百万行到临时表可能触发 work_mem 不足或 OOM。应控制单次 INSERT 行数，推荐 1000–5000 行/批：
COPY tmp_update_data FROM STDIN WITH (FORMAT CSV); -- 应用层分批发送CSV流 -- 或用循环： INSERT INTO tmp_update_data SELECT id, new_status, now() FROM staging_batch WHERE batch_id = 1 LIMIT 5000;
- 用
COPY比多条INSERT快 5–10 倍，尤其配合客户端流式写入 - 临时表无需
VACUUM，但若批次过多，可显式TRUNCATE tmp_update_data清空后重用 - 不要依赖
cursor%found判断最后一批——当剩余行不足 LIMIT 时，%found可能为 false 导致漏数据
容易被忽略的锁与事务陷阱
临时表本身不锁主表，但 UPDATE ... FROM 仍会对匹配到的目标行加 ROW EXCLUSIVE 锁。若一次更新太多行，可能阻塞其他查询或引发锁等待超时：
- 务必用小范围
WHERE限制每次UPDATE的行数，例如：WHERE o.id BETWEEN 10000 AND 15000 AND o.id IN (SELECT id FROM tmp_update_data) - 整个流程要包在事务里，但别让事务跨批次——每批
UPDATE后立即COMMIT，释放锁并减少 WAL 压力 - 如果主表有外键引用或触发器，
UPDATE FROM仍会触发它们；禁用触发器需SET session_replication_role = 'replica'（仅限维护期，且需 superuser 权限）
真正卡住的往往不是语法，而是没意识到临时表只是“搬运工”，最终那条 UPDATE 依然受主表索引质量、并发负载、WAL 配置影响——先跑 EXPLAIN ANALYZE 看执行计划里是不是用了 Hash Join 和 Index Scan，再动手。
