Oracle中直接UPDATE大表会卡死，主因是未走索引导致全表扫描、锁升级为表级锁、undo/redo日志暴涨；必须用BULK COLLECT+LIMIT+FORALL分批处理，每批 COMMIT 前校验 v_ids.COUNT=0，并建 status+id 复合索引确保走索引。
为什么直接 UPDATE ... WHERE status = 'pending' 会卡死
Oracle 对百万级单条 UPDATE 语句的响应极差：锁升级成表级锁、redo 日志暴涨、undo 表空间撑满，甚至触发 ORA-01555。这不是 SQL 写得不对，而是 Oracle 的事务机制天然不支持“一把梭”。你看到的“卡住”，其实是数据库在等 undo 段释放、等 checkpoint 完成、或在反复尝试获取行锁。
必须用 BULK COLLECT + LIMIT + FORALL 分批处理
这是 Oracle 19c 及以上版本批量更新的唯一可靠路径。WHILE 循环 + 单行 SELECT INTO 是性能黑洞，每轮都全量扫描、PGA 内存爆涨、上下文切换频繁。
-
LIMIT值设为 200～500：实测LIMIT 300在多数硬件上吞吐与内存占用最平衡；超过 500 容易触发 PGA 自动扩展，反而拖慢 - 游标里加
/*+ INDEX(orders idx_status_id) */强制走索引，WHERE status = 'pending'字段必须和主键/排序字段组成复合索引，否则每次 FETCH 都全表扫 -
FETCH c_orders BULK COLLECT INTO v_ids LIMIT 300后，**必须检查v_ids.COUNT = 0才退出循环**，%NOTFOUND在 LIMIT 场景下不可靠 - FORALL 更新时用
SAVE EXCEPTIONS，避免某条出错导致整批失败，后续可查SQL%BULK_EXCEPTIONS
每批 COMMIT 的节奏怎么定
不是“越多越好”，也不是“越少越好”。1000 行一次是经验值起点，但要根据你的行宽调优：如果每行平均 2KB，1000 行就是 2MB redo，I/O 压力可控；若行宽达 20KB，就该降到 100 行/批。
- 别在 FORALL 里写
COMMIT—— 它只对当前 PL/SQL 块生效，且会中断事务一致性 - COMMIT 放在 FORALL 之后、FETCH 之前，确保本批全部成功再落盘
- 加异常块捕获
ORA-00060（死锁）并重试，而不是让整个过程崩掉 - 用
DBMS_APPLICATION_INFO.SET_MODULE打标记，方便在v$session里实时追踪进度
容易被忽略的索引与统计信息陷阱
即使写了 LIMIT + BULK，如果 status 字段上没索引，或者索引失效（比如用了 UPPER(status)），游标第一次 FETCH 就会全表扫描，后面所有优化都白搭。
- 建复合索引：
CREATE INDEX idx_orders_status_id ON orders(status, id) NOLOGGING;——NOLOGGING减少建索引本身日志开销 - 执行前跑
EXEC DBMS_STATS.GATHER_TABLE_STATS('SCHEMA_NAME', 'ORDERS');，尤其当订单表刚经历大批量 INSERT - 别信“我这个字段肯定有索引”，用
EXPLAIN PLAN FOR SELECT id FROM orders WHERE status = 'pending' AND id > :min_id;看是否真走了索引
