TRUNCATE不支持WHERE条件，仅适用于全表清空；条件删除应使用分批DELETE配合ROWID和显式COMMIT。误用TRUNCATE会导致语法报错（ORA-00903）及HWM重置、索引失效等副作用。
truncate 不能带 where，想条件删就别碰它；真要高效删大批量数据，得靠 pl/sql 分批 + rowid + 显式 commit。
TRUNCATE 只适合全表清空，用错场景反而拖慢整体节奏
很多人一看到“删得快”就直奔 TRUNCATE TABLE，但它只适用于：表里所有数据都要扔，且不关心回滚、触发器、外键约束（或已提前处理）。一旦加了 WHERE 条件，TRUNCATE 就语法报错——它压根不支持条件。
常见误用：TRUNCATE TABLE orders WHERE status = 'CANCELLED' → 直接报 ORA-00903: invalid table name。这不是权限问题，是语法根本不允许。
另外注意：TRUNCATE 会重置高水位线（HWM），但也会立刻释放空间、失效索引、清空回收站（如果开启），这些副作用在某些运维流程里可能触发告警或下游同步异常。
DELETE 单次执行百万行？大概率卡死或报 ORA-01555/ORA-01562
直接写 DELETE FROM sales WHERE sale_date 看似简单，但 Oracle 会为每一行生成完整 undo 记录，锁住对应数据块的 ITL 槽，还可能撑爆 UNDO 表空间。尤其当表没分区、没索引、或条件字段上函数多（比如 TO_CHAR(sale_date, 'YYYYMM')）时，执行计划容易走全表扫描，几小时都删不完。
- UNDO 空间不足 → 报
ORA-01562: failed to extend rollback segment - 其他会话查老快照 → 报
ORA-01555: snapshot too old - 事务太长 → DBA 不敢 kill，怕回滚要半天
这不是性能调优问题，是事务设计缺陷。
PL/SQL 分批删的核心是：先捞 ROWID，再按批删，每批后 COMMIT
ROWID 是 Oracle 内部最轻量的物理定位方式，不依赖索引，也不受函数影响。关键是不能把条件塞进 DELETE 的子查询里反复计算，而要拆成两步：
① 查出一批符合条件的 ROWID（带 ROWNUM 限流，且业务条件尽量走索引）
② 用这批 ROWID 做精准删除
示例逻辑：
DECLARE
v_batch_size NUMBER := 5000;
BEGIN
LOOP
DELETE FROM orders
WHERE ROWID IN (
SELECT ROWID FROM (
SELECT ROWID
FROM orders
WHERE status = 'PROCESSED'
AND create_time <p>要点：</p>
- 子查询里必须有
AND ROWNUM ，否则 CBO 可能先全扫再截断 - 条件字段（如
create_time）要有索引，避免函数写法（TRUNC(create_time)会失效） - 批次大小设 5000–10000，太小导致日志切换频繁，太大易触 UNDO 限制
- 别用
FORALL直接删原始条件——它不解决扫描代价，只是批量发 SQL
真正大批量删（千万级+）优先考虑分区表或重建表
如果表本身没分区，又常要按时间删旧数据，现在补分区成本高，不如换种思路：
- 建新表保留有效数据：
CREATE TABLE orders_new NOLOGGING AS SELECT * FROM orders WHERE create_time >= DATE '2022-01-01' - 原子替换：
DROP TABLE orders; ALTER TABLE orders_new RENAME TO orders - 手动重建索引、约束、统计信息（
DBMS_STATS.GATHER_TABLE_STATS）
这招比任何 PL/SQL 都快，但要求业务能接受短暂停写，且 DDL 权限到位。另外注意：NOLOGGING 在归档模式下仍会写 minimal redo，不是完全零日志。
最后提醒一句：无论选哪种方式，删前务必确认备份可用，且条件 WHERE 子句在测试库跑过执行计划——生产环境里，WHERE 写错一个字符，删掉的就是整个月的订单。
