Oracle禁止对启用外键约束的父表执行TRUNCATE，因TRUNCATE是不校验外键的DDL操作，会直接报ORA-02266错误；唯一可行方案是先DISABLE外键、TRUNCATE、再ENABLE外键。
外键约束下 TRUNCATE 父表直接报错
Oracle 不允许对存在启用外键约束的父表执行 TRUNCATE TABLE，哪怕子表当前为空。这不是语法限制，而是 Oracle 的强制完整性保护机制：TRUNCATE 是 DDL 操作，不走事务日志、不可回滚，且会重置高水位线，因此无法触发外键级联逻辑（如 ON DELETE CASCADE），也无法逐行校验子表引用状态。
常见错误信息是：ORA-02266: unique/primary keys in table referenced by enabled foreign keys。注意关键词是 enabled —— 只要外键状态为 ENABLED，哪怕子表没数据，TRUNCATE 也会被拒。
- 不能靠先清空子表再 TRUNCATE：TRUNCATE 本身不检查子表是否为空，只看外键是否启用
-
DELETE FROM parent_table可以成功（如果配了ON DELETE CASCADE），但它是 DML，性能差、占 UNDO、需 COMMIT - 分区表场景更敏感：即使只想
TRUNCATE PARTITION，只要该分区所属父表有启用的外键，同样被拦
分区表 + 外键 = 分区管理能力受限
Oracle 明确限制：一旦父表启用了外键约束，就无法对它的任何分区执行 TRUNCATE PARTITION 或 DROP PARTITION。这不是 bug，是设计取舍 —— 分区 DDL 操作无法与子表数据状态做原子协调。
典型现象：执行 ALTER TABLE t_parent TRUNCATE PARTITION p_old 时抛出 ORA-14054: cannot truncate partition of a table with enabled foreign key constraints。
- 即使子表也做了相同分区策略（比如引用分区），该限制依然存在
- 唯一绕过方式是临时禁用外键：
ALTER TABLE t_child DISABLE CONSTRAINT fk_t_child，操作完再ENABLE - 禁用期间，子表可插入非法值（父表不存在的键），必须确保业务无写入或有额外校验
DISABLE vs DROP 外键：选哪个更安全？
想快速清空父表又保留外键逻辑，两种主流做法：禁用（DISABLE）或删除后重建（DROP + ADD）。实际选型要看约束复杂度和维护成本。
-
DISABLE更轻量：不改元数据结构，不重新编译依赖对象，速度极快；但需手动保证子表数据一致性 -
DROP+ADD更彻底：约束名、索引、状态全部重置；但如果原约束带ON DELETE CASCADE，重建时容易漏写，导致后续删除行为异常 - 分区表场景强烈建议用
DISABLE：因为重建外键后，Oracle 不会自动继承原分区关联逻辑，可能破坏分区剪枝效果
为什么 ON DELETE CASCADE 对 TRUNCATE 无效？
ON DELETE CASCADE 只在 DELETE 语句中生效，它依赖触发器和事务上下文逐行处理子表。而 TRUNCATE 绕过所有这些机制，直接释放段空间，所以即使定义了级联，TRUNCATE 仍被禁止。
这是最容易误解的一点：很多人以为“加了 cascade 就能 truncate”，结果在生产环境踩坑。真正能配合 TRUNCATE 的，只有禁用外键这一条路。
分区表尤其要注意：禁用外键后执行 TRUNCATE PARTITION，完成后若忘记 ENABLE，后续应用插入子表时可能因外键失效而写入脏数据，这种问题往往延迟暴露。
