直接update join卡住百万级数据，是因为数据库退化为嵌套循环连接，每匹配一行就全表扫描被驱动表一次，导致百万次磁盘io及日志、索引等开销线性放大。
为什么直接UPDATE JOIN会卡住百万级数据
不是SQL写错了，而是数据库在“反复做同一件事”。比如 UPDATE a JOIN b ON a.id = b.id SET a.status = b.status，当 b 表没有索引、或 a.id 与 b.id 类型不一致（如一个是 VARCHAR，一个是 BIGINT），MySQL/PostgreSQL 就可能退化成嵌套循环（NLJ），每匹配一行都要全表扫 b —— 百万次扫描，就是百万次磁盘 IO。更糟的是，每行更新还触发 MVCC 版本生成、redo 日志刷盘、所有索引重建，开销呈线性放大。
临时表必须带主键或唯一索引
临时表不是“随便建个表放数据”就行。如果漏掉约束，UPDATE ... FROM tmp 或 UPDATE a JOIN tmp ON ... 很可能走不了索引连接，最终 fallback 到 Nested Loop + 全表扫描，比原语句还慢。
-
CREATE TEMP TABLE tmp_data (id BIGINT PRIMARY KEY, new_status TEXT)—— 明确声明主键，让优化器优先选 Index Scan 或 Hash Join - 若关联字段不是主键（比如用业务单号
order_no），必须显式加唯一索引：CREATE UNIQUE INDEX idx_order_no ON tmp_data(order_no) - PostgreSQL 中，临时表默认不继承主表索引，也不能依赖“自动推断”，
EXPLAIN看到Seq Scan on tmp_data就得立刻补索引
分批写入临时表，别一次性灌几百万行
把 200 万条待更新数据一次性 INSERT INTO tmp_data SELECT ...，极易触发 work_mem 不足（PostgreSQL）或 max_allowed_packet 超限（MySQL），导致内存溢出或连接中断。实测中，单批 5000 行是较稳的甜点。
- 用
COPY（PostgreSQL）或LOAD DATA INFILE（MySQL）代替多条INSERT，吞吐快 5–10 倍 - 应用层分批次查源数据，每批
LIMIT 5000，再批量写入临时表，避免游标漏数据（cursor%found在最后一批常为 false） - 写完一批后，可显式
TRUNCATE tmp_data清空重用，省去反复建表开销
UPDATE FROM 的 WHERE 条件不能碰函数
哪怕只加一个类型转换，也会让索引失效。比如主表 id 是 BIGINT，临时表 id 是 VARCHAR，写成 WHERE a.id = t.id::BIGINT 或 WHERE a.id = CAST(t.id AS SIGNED)，PostgreSQL 和 MySQL 都会放弃走索引，转而全表扫描主表 —— 这是线上最常被忽略的性能断崖点。
- 建临时表时就统一字段类型，和主表严格对齐；宁可应用层转换，也不在 SQL 里 cast
-
EXPLAIN必须看到Index Cond: (a.id = t.id)或Hash Cond: (a.id = t.id)，而不是Filter: (a.id = t.id::bigint) - 如果主表关联字段无索引，先加索引再跑临时表方案；否则整个优化白搭
UPDATE ... FROM 仍会对匹配到的每一行加行级锁。如果你的更新涉及热点数据（比如状态字段集中更新某几千个 ID），锁等待时间可能反超计算时间 —— 这时候得结合业务，考虑是否拆成更小批次，或错峰执行。
