truncate不能直接写在存储过程中，必须用execute immediate调用，因其属ddl语句，pl/sql编译器在解析阶段即拒绝，报pls-00103错误；它隐式提交、重置hwm、绕过触发器，与pl/sql事务上下文冲突。
TRUNCATE 不能直接写在存储过程中，必须用 EXECUTE IMMEDIATE 调用 —— 这不是偷懒或绕弯，而是 Oracle PL/SQL 引擎的硬性限制。
为什么 TRUNCATE 在存储过程中会报 PLS-00103 错误
PL/SQL 编译器只允许在块中直接使用 DML（INSERT/UPDATE/DELETE）和事务控制语句（COMMIT/ROLLBACK）。TRUNCATE 是 DDL，它隐式提交、重置高水位线、绕过触发器，这些行为与 PL/SQL 的事务上下文冲突。编译时引擎看到 TRUNCATE TABLE t1 就直接拒绝，抛出 PLS-00103: Encountered the symbol "TRUNCATE"。
- DDL 在 Oracle 中被视为“会话级顶级操作”，不能嵌套在 PL/SQL 块内部执行
- 即使加了
EXCEPTION块也拦不住这个编译错误——它发生在运行前 - 试图用
CREATE OR REPLACE PROCEDURE包裹TRUNCATE同样失败，本质未变
如何安全封装 TRUNCATE 到存储过程
核心就一条：把表名作为参数传入，用 DBMS_ASSERT.SQL_OBJECT_NAME 校验后再拼进字符串，最后交给 EXECUTE IMMEDIATE 执行。
- 绝不能写
EXECUTE IMMEDIATE 'TRUNCATE TABLE ' || v_table_name—— 这是 SQL 注入温床 - 必须用
DBMS_ASSERT.SQL_OBJECT_NAME(v_table_name)过滤非法字符和跨 schema 引用 - 如果传入的表名含 schema（如
'SCOTT.EMP'），SQL_OBJECT_NAME默认只校验对象名，需改用DBMS_ASSERT.ENQUOTE_NAME或自行拆解 + 双重校验 -
TRUNCATE隐式提交，执行后前面所有未提交的 DML 都会立即落库，无法回滚
CREATE OR REPLACE PROCEDURE truncate_table_safe(p_table_name IN VARCHAR2) AS
v_sql VARCHAR2(200);
BEGIN
v_sql := 'TRUNCATE TABLE ' || DBMS_ASSERT.SQL_OBJECT_NAME(p_table_name);
EXECUTE IMMEDIATE v_sql;
EXCEPTION
WHEN OTHERS THEN
RAISE_APPLICATION_ERROR(-20001, 'Truncate failed on ' || p_table_name || ': ' || SQLERRM);
END;
什么时候该用 TRUNCATE 而不是 DELETE？别只看“清空”两个字
选错会导致性能雪崩、锁表超时、归档日志暴涨，甚至业务中断。
- 要快速释放空间、重置 HWM、后续插入不浪费空块 → 必须用
TRUNCATE - 需要触发器响应、要回滚、表被外键引用且没开
CASCADE→ 只能用DELETE - 大表全删但又不敢用
TRUNCATE？分批DELETE+COMMIT是下策，HWM 不降，统计信息易失真 -
TRUNCATE不记 undo，闪回查询（AS OF TIMESTAMP）对它无效；DELETE有完整 undo 链
容易被忽略的权限和依赖细节
即使语法和校验都对了，仍可能在运行时报错，原因往往藏在权限链或对象状态里。
- 执行者必须对目标表有
DROP ANY TABLE或该表上的ALTER权限（注意：TRUNCATE实际依赖的是ALTER，不是DELETE权限） - 如果表上有启用的
BEFORE/AFTER STATEMENT触发器，TRUNCATE会跳过它们 —— 这不是 bug，是设计使然 - 物化视图日志表、AQ 队列表等系统管理表，
TRUNCATE可能被显式禁止，报ORA-14404或ORA-30000类错误 - 存储过程定义者权限（definer's rights）下执行时，权限检查发生在调用时刻，不是编译时刻 —— 所以授权要给到过程拥有者，而非调用者
