应使用ROWID或平行简单类型集合替代%ROWTYPE配合FORALL更新，因%ROWTYPE无法承载动态WHERE条件且字段匹配风险高；ROWID定位精确、性能优，平行集合需严格长度一致并预过滤NULL。（截至2026年7月27日）
FORALL 批量更新在 Oracle 中确实能显著减少上下文切换，但直接套用 FORALL 更新表数据时，最容易出错的不是语法，而是集合结构、WHERE 条件绑定方式、以及空集合或稀疏下标导致的静默失败。
为什么不能直接用 %ROWTYPE 集合配 FORALL UPDATE？
FORALL 要求 DML 语句中所有绑定变量都来自同一集合的对应下标，而 %ROWTYPE 集合（如 TYPE t_tab IS TABLE OF my_table%ROWTYPE）在 UPDATE ... SET ROW = ... 场景下看似方便，但实际有硬限制：
-
UPDATE ... SET ROW = v_tab(i)仅在目标表字段顺序、类型、数量完全匹配且无虚拟列时才安全； - 更常见的是按主键或唯一键定位更新，此时必须显式写出
WHERE条件，且条件字段也得来自集合 —— 但%ROWTYPE集合里若没存主键值，就根本没法写WHERE id = v_tab(i).id； - 实际项目中多数更新逻辑依赖非主键字段（如
WHERE status = 'P' AND dept_id IN (...)），这类条件无法靠单个行记录承载。
所以，更稳妥的做法是：用简单类型集合分别存 ID 和新值，或用 ROWID 定位。
用 ROWID + FORALL 实现稳定批量更新
ROWID 是 Oracle 行的物理地址，更新时绕过索引查找，性能高且定位绝对精确。配合 FORALL 是生产环境最推荐的方式之一：
- 游标只查
ROWID，不加载整行数据，内存占用低； -
FORALL更新语句中直接引用v_rowid_tab(i)，无需额外 WHERE 条件解析； - 即使表无主键或唯一约束也能安全使用。
关键点：
-
v_rowid_tab类型必须是DBMS_SQL.UROWID_TABLE或TABLE OF UROWID； - FETCH 时务必加
LIMIT，否则大结果集可能 OOM； - 必须用
SAVE EXCEPTIONS，否则某条失败整个FORALL就中断； -
SQL%BULK_EXCEPTIONS.COUNT只在异常块中有效，且需声明PRAGMA EXCEPTION_INIT(v_error, -24381)捕获批量错误。
示例片段：
DECLARE
TYPE rid_tab IS TABLE OF UROWID;
v_rid rid_tab;
CURSOR c_upd IS SELECT ROWID FROM orders WHERE status = 'NEW';
BEGIN
OPEN c_upd;
LOOP
FETCH c_upd BULK COLLECT INTO v_rid LIMIT 5000;
EXIT WHEN v_rid.COUNT = 0;
<pre class='brush:php;toolbar:false;'>BEGIN
FORALL i IN 1..v_rid.COUNT SAVE EXCEPTIONS
UPDATE orders SET status = 'PROCESSED', updated_at = SYSDATE
WHERE ROWID = v_rid(i);
EXCEPTION
WHEN OTHERS THEN
IF SQL%BULK_EXCEPTIONS.COUNT > 0 THEN
FOR j IN 1..SQL%BULK_EXCEPTIONS.COUNT LOOP
DBMS_OUTPUT.PUT_LINE('Failed at index ' || SQL%BULK_EXCEPTIONS(j).ERROR_INDEX);
END LOOP;
END IF;
END;END LOOP; CLOSE c_upd; END;
FORALL UPDATE 的 WHERE 条件怎么安全传参？
如果不用 ROWID，又必须按业务字段（比如 order_no）更新，那就得用多个平行集合：
- 一个存
order_no（TYPE no_tab IS TABLE OF orders.order_no%TYPE）； - 一个存新状态（
TYPE stat_tab IS TABLE OF orders.status%TYPE）； -
FORALL中用相同下标同时取值：UPDATE orders SET status = v_stat(i) WHERE order_no = v_no(i)。
注意：
- 两个集合长度必须严格一致，否则运行时报
ORA-06532: Subscript outside of limit； - 不能用
INDICES OF或VALUES OF语法混用不同集合，FORALL只认一个集合的下标范围； - 如果某些记录要跳过更新（比如校验失败），得先过滤再
EXTEND到新集合，而不是在原集合里置 NULL —— 因为NULL仍算“有值”，FORALL i IN 1..count会执行到它，导致WHERE order_no = NULL永远不成立，变成静默漏更新。
limit 值设多少才合理？
LIMIT 不是越大越好，也不是越小越稳，它本质是在 PGA 内存、网络传输、事务回滚段大小、锁持有时间 之间找平衡：
- 太小（如 100）：上下文切换次数多，性能提升有限；
- 太大（如 100000）：PGA 瞬间暴涨，可能触发
ORA-04030（内存不足），或单次事务太长，阻塞其他会话； - 经验值：1000–10000 是较安全区间，具体看单行数据大小 —— 如果每行平均 2KB，10000 行就是约 20MB PGA；
更重要的是：无论设多少，都必须检查 v_collection.COUNT 是否为 0 再进循环，别依赖 %FOUND —— 最后一次 FETCH 若不满 LIMIT，%FOUND 为 FALSE，但集合已有数据。
真正容易被忽略的，是 FORALL 更新后，你没法直接拿到每条语句影响的行数（SQL%ROWCOUNT 返回的是本次 FORALL 总影响行数）。需要逐行效果，只能退回到单条 UPDATE，或者改用 RETURNING BULK COLLECT INTO —— 但那又要求你明确知道哪些字段要返回，且不能用于 UPDATE ... SET ROW = ... 形式。
