触发器中禁止用EXECUTE IMMEDIATE做分表归档，因其破坏事务原子性、引发mutating table错误、导致数据不一致；正确方案是采用RANGE/INTERVAL分区表配合ALTER TABLE DROP/EXCHANGE PARTITION实现归档。
触发器里不能直接用 EXECUTE IMMEDIATE 做分表归档
直接在触发器中写 EXECUTE IMMEDIATE 动态插入到不同历史表（比如 orders_2025、orders_2026）是危险且不可靠的。触发器主体运行在 DML 事务上下文中，而 EXECUTE IMMEDIATE 执行 DDL（如 CREATE TABLE）会隐式提交，破坏事务原子性；执行 DML 则受限于行级触发器中对“正在修改的表”的读写限制（ORA-04091 mutating table error）。更关键的是：Oracle 触发器不允许在 BEFORE 或 AFTER ROW 中发起跨表 INSERT，除非用自治事务（PRAGMA AUTONOMOUS_TRANSACTION），但自治事务会脱离原事务一致性，导致归档成功而主表操作回滚时数据不一致。
INSERT ... SELECT + 分区表才是正解，不是触发器动态路由
所谓“自动分表归档”，本质是按时间或业务维度把数据物理隔离——这该由分区表承担，而不是靠触发器拼表名。正确路径是：
- 把源表建为
RANGE或INTERVAL分区表（如按order_date每月一分区） - 归档动作是
ALTER TABLE ... DROP PARTITION或EXCHANGE PARTITION到归档表，全程 DDL 控制，不依赖行级逻辑 - 如果必须用触发器辅助，只用于标记（如更新
archived_flag）、记录日志（写入独立日志表），而非搬运数据 -
EXECUTE IMMEDIATE真要动态路由，只能放在存储过程中，由定时任务（DBMS_SCHEDULER）调用，且必须显式处理异常、锁、统计信息刷新
真要用触发器+动态SQL，必须加自治事务并放弃事务一致性
若业务强要求每条 INSERT 都立刻落历史表（例如审计类场景），可这样写，但得接受后果：
- 触发器开头必须声明
PRAGMA AUTONOMOUS_TRANSACTION - 所有
INSERT INTO orders_his_||TO_CHAR(:new.order_date,'YYYYMM')类操作，需用EXECUTE IMMEDIATE拼接完整语句 - 每次执行后必须
COMMIT，否则自治事务不生效 - 无法回滚：主表 INSERT 失败，历史表已写入，数据分裂
- 性能极差：每行触发一次硬解析 + 事务切换，4亿行表会直接拖垮 LGWR
容易被忽略的三个硬约束
即使绕过 mutating table 问题强行上动态路由，还有三处 Oracle 底层卡点：
-
EXECUTE IMMEDIATE在触发器中不能执行CREATE TABLE—— DDL 会报 ORA-00103，因触发器禁止会话级对象变更 - 目标历史表名若含变量（如
orders_his_202605），必须提前建好，且触发器用户要有 INSERT 权限，不能靠触发器自动建 - 分区表的
INTERVAL自动分裂机制与触发器无关，它只响应 INSERT 的分区键值，不看触发器逻辑；指望触发器“驱动”新分区生成，是混淆了机制层级
归档真正的复杂点不在语法，而在数据边界控制和事务语义取舍——用触发器做实时路由，等于把应用层的分片逻辑塞进数据库内核通道，稍有并发或异常就断流。稳住的方式，永远是分区表 + 定时作业 + 显式 DDL 控制。
