大事务需分批更新以避免Undo空间爆满：先COUNT(*)确认总行数，按有索引的业务主键或时间字段切片，每批5k–20k行，循环中显式COMMIT，并注意ROWNUM非排序工具、索引缺失等常见陷阱。
Undo空间爆满时，UPDATE直接卡住或报ORA-01555、ORA-30036
oracle里大事务不拆分，undo表空间撑不住是常态。不是undo配小了，而是单次update扫描+修改行数太多，undo段要全程保留旧镜像，直到事务提交。一卡就是几十分钟，还可能拖垮其他会话。
实操建议：
- 先用
SELECT COUNT(*)确认待更新总行数，别盲目开跑 - 按业务主键或时间字段（如
create_time）切片，优先选有索引的列，避免全表扫 - 每批控制在 5k–20k 行之间：太小（如100行）触发频繁日志切换和SCN推进，开销反升；太大（如10w+）Undo压力仍高，且失败后重试成本高
- 务必在循环中显式加
COMMIT，别依赖自动提交——PL/SQL块里没COMMIT就等于没拆
用ROWNUM分页更新容易错在“伪列不保证顺序”
ROWNUM不是排序工具，它在过滤前就编号。如果直接写WHERE ROWNUM ，可能每次取到的都是前N行，但因未<code>ORDER BY，实际批次间会漏数据或重复更新。
正确做法是结合子查询+确定性排序：
UPDATE my_table
SET status = 'done'
WHERE id IN (
SELECT id FROM (
SELECT id FROM my_table
WHERE create_time >= DATE '2024-01-01'
AND create_time < DATE '2024-02-01'
ORDER BY id -- 必须有，且字段要有索引
)
WHERE ROWNUM <= 10000
);注意：ORDER BY字段必须有索引，否则子查询排序本身就会拖慢甚至引发临时表空间不足。
按日期范围拆分时，create_time字段类型和索引失效是隐形坑
常见错误是把DATE字段和字符串硬比较，比如create_time >= '2024-01-01'，触发隐式类型转换，导致索引失效，每批都变全表扫描。
安全写法只用两种：
create_time >= DATE '2024-01-01' AND create_time （推荐，清晰、无歧义）-
TRUNC(create_time) = DATE '2024-01-01'（慎用，TRUNC()会跳过普通索引，需函数索引支持）
检查执行计划是否走了索引：看PLAN_TABLE里ACCESS_PREDICATES是否含你的日期字段，而不是只看FILTER_PREDICATES。
批量提交后查不到刚改的数据？别急着怀疑逻辑，先看READ COMMITTED隔离级
Oracle默认隔离级别是READ COMMITTED，你自己的会话在提交前看不到自己改的行（除非用SELECT ... FOR UPDATE），别人也看不到，直到你COMMIT。这不是Bug，是机制。
验证是否真生效，得另起一个会话查：
SELECT COUNT(*) FROM my_table WHERE status = 'done' AND create_time >= DATE '2024-01-01';
另外，如果用PL/SQL块循环+COMMIT，记得每批后加DBMS_LOCK.SLEEP(0.1)（可选），缓解Undo段争用，尤其在RAC环境。
最麻烦的不是怎么拆，而是拆完发现时间字段没索引、条件写成字符串、或者忘了在子查询里ORDER BY——这些地方一错，表面在“分批”，实际还是在扫全表。
