oracle存储过程中不能直接写ddl语句，因编译期语法禁止且ddl会隐式提交破坏事务原子性；必须用execute immediate动态执行字符串形式的ddl。
不能直接写 CREATE TABLE，必须用 EXECUTE IMMEDIATE 包一层，否则编译就报错。
为什么存储过程里不能直接写 DDL 语句
Oracle 在编译存储过程时会做语法检查，而 CREATE、DROP、TRUNCATE 这类 DDL 语句不被允许作为 PL/SQL 可执行语句直接出现。一旦你写成：
CREATE PROCEDURE p1 AS BEGIN CREATE TABLE t1 (id NUMBER); -- 编译失败：PLS-00103 END;
就会立刻报 PLS-00103 错误，根本不会生成有效对象。这不是权限问题，是语法层面的硬性限制。
根本原因是：DDL 会隐式触发 COMMIT，而 PL/SQL 块默认运行在单个事务上下文中，Oracle 不允许在常规 PL/SQL 执行流中混入事务边界变动操作。
EXECUTE IMMEDIATE 是怎么绕过编译检查的
EXECUTE IMMEDIATE 把 DDL 当作字符串传入，在运行时才解析执行，跳过了编译期校验。它本质是动态 SQL 的执行入口，所以：
- 字符串内容不会被 PL/SQL 编译器提前分析，只要语法合法、运行时权限足够，就能过
- 每次执行都独立触发隐式
COMMIT，所以后续语句（比如 INSERT）属于新事务 - 错误只能在运行时报，比如表已存在、权限不足，错误码是
ORA-00955或ORA-01031
示例：
CREATE OR REPLACE PROCEDURE create_log_table AS
BEGIN
EXECUTE IMMEDIATE 'CREATE TABLE log_202605 (ts DATE, msg VARCHAR2(200))';
EXCEPTION
WHEN OTHERS THEN
IF SQLCODE = -955 THEN NULL; -- 表已存在，忽略
ELSE RAISE;
END IF;
END;
常见坑：权限、自治事务与触发器场景
即使语法对了，运行时仍可能失败，关键点有三个：
-
EXECUTE IMMEDIATE执行 DDL 依赖的是存储过程所有者的权限，不是调用者权限。如果用户 A 创建了过程，用户 B 调用却没建表权限，会报ORA-01031。解决办法是加AUTHID CURRENT_USER - 在触发器里执行 DDL 必须用自治事务，否则报
ORA-04092（cannot commit in a trigger）。需在过程开头加PRAGMA AUTONOMOUS_TRANSACTION;，并在结尾显式COMMIT; - DDL 字符串里不能直接拼接变量，要用绑定或字符串拼接。错误写法：
'CREATE TABLE ' || tab_name || ' (id NUMBER)'—— 如果tab_name含非法字符或 SQL 注入风险，就炸了；稳妥做法是用DBMS_ASSERT.SIMPLE_SQL_NAME校验
替代方案：什么时候不该用 EXECUTE IMMEDIATE
DDL 动态化不是银弹。以下情况应避免：
- 表结构固定、部署期可预知：直接用脚本建表，别塞进存储过程
- 高频调用的存储过程：每次执行都
CREATE/DROP表，严重拖慢性能，也容易锁表 - 需要事务一致性保障的操作：比如“先删旧表再插新数据”，DDL 的隐式
COMMIT会让前序 DML 独立提交，无法回滚
真正适合的场景其实很窄：按日/月自动归档建表、ETL 中临时中间表、权限隔离下的动态对象管理。多数时候，DDL 应该从存储过程中剥离出去，由部署流程或 DBA 统一管控。
