on delete cascade 在分区表上生效，但仅限外键约束明确定义该选项；oracle 分区不影响外键逻辑，仅改变数据分布；若子表分区且外键含 cascade，则父表删除会自动清理所有匹配分区中的子记录。
ON DELETE CASCADE 在分区表上是否生效？
生效，但仅限于外键约束本身定义时明确指定了 ON DELETE CASCADE。Oracle 分区表不改变外键行为逻辑——它只影响数据物理分布。如果你的子表是分区表（比如按时间范围分区的 order_items），只要外键约束带 ON DELETE CASCADE，父表记录删除时，所有匹配分区中的子记录仍会被自动清理。
常见错误现象是：删了父表某条记录，子表数据还在。这不是分区导致的，而是外键根本没加 ON DELETE CASCADE，或者加了但建约束时用了 DISABLE 或 NOVALIDATE 状态。
- 检查外键是否启用且带级联：
SELECT constraint_name, delete_rule, status FROM user_constraints WHERE table_name = '子表名' AND constraint_type = 'R'; - 如果
delete_rule是NO ACTION或为空，说明没设级联；如果是CASCADE但status是DISABLED，得先ALTER TABLE ... ENABLE CONSTRAINT - 分区表上加外键约束无特殊语法，但要注意：被引用的父表主键/唯一键字段必须是分区键的子集或包含在分区键中，否则 Oracle 会报
ORA-14097
用 DROP TABLE CASCADE CONSTRAINTS 删除分区表时会连带删父表吗？
不会。这个 CASCADE CONSTRAINTS 只删当前表上的外键约束（即“别人指向我的”那些约束），不删“我指向别人的”外键，更不删父表本身。
典型误操作场景：你执行了 DROP TABLE sales_part CASCADE CONSTRAINTS;，结果发现 departments 表里某些部门记录没了——这说明 sales_part 其实是父表，而 departments 是子表，且子表外键设了 ON DELETE CASCADE。此时真正被级联删掉的是 departments，不是 sales_part。
-
DROP TABLE ... CASCADE CONSTRAINTS的作用对象是「当前表所承载的约束」，不是「当前表作为父表时的级联行为」 - 想安全删分区表又不影响父表？先确认该表是否被其他表通过外键引用：
SELECT owner, constraint_name, r_constraint_name FROM all_constraints WHERE r_constraint_name IN (SELECT constraint_name FROM all_constraints WHERE table_name = '当前表名' AND owner = '当前用户'); - 如果查到有引用，且你确定要保留父表，删前务必先
ALTER TABLE 子表 DROP CONSTRAINT 外键名，而不是依赖CASCADE CONSTRAINTS
分区表 + ON DELETE CASCADE 的性能隐患在哪？
当父表一条记录被删，Oracle 必须扫描所有子表分区，定位并删除匹配的子记录。如果子表是按 LIST 或 RANGE 分区但外键列不是分区键，就可能触发全分区扫描，I/O 和锁等待明显升高。
例如：子表 log_events 按 event_date RANGE 分区，但外键指向父表 users 的 user_id；删一个 user_id = 123，Oracle 得挨个检查每个分区文件，因为无法根据 user_id 定位具体分区。
- 最佳实践：把外键列纳入分区键，或至少作为分区键的第一部分（如
PARTITION BY RANGE (user_id, event_date)） - 避免在高频删除的父表上对大分区子表启用
ON DELETE CASCADE；改用应用层分批 delete + commit，配合/*+ PARALLEL */提示 - 监控实际执行计划：
EXPLAIN PLAN FOR DELETE FROM parent WHERE id = 123;，再查PLAN_TABLE看是否出现PARTITION LIST ALL（意味着全分区扫描）
DROP USER CASCADE 对分区表对象的影响
执行 DROP USER xxx CASCADE 会删掉该用户下所有对象，包括分区表、分区索引、本地索引、全局索引等，但不会自动清理这些分区表所依赖的父表（哪怕父表在另一个用户下）。关键在于：如果该用户下有子表设了 ON DELETE CASCADE 指向其他用户的父表，DROP USER CASCADE 不会触发任何级联删除动作——级联只发生在 DML（如 DELETE）时，不发生在 DDL（如 DROP）时。
容易被忽略的一点是：分区表的元数据（如 USER_TAB_PARTITIONS 记录）会被清空，但对应的数据文件（.dbf）里的物理块不会立即释放。即使用户和所有表都删了，表空间若未被显式 drop，那些空间仍在磁盘上占着。
- 删用户前，先确认该用户下是否有表被其他用户外键引用：
SELECT owner, table_name, constraint_name FROM all_constraints WHERE r_owner = '目标用户名' AND constraint_type = 'R'; - 删完后若需释放磁盘空间，得额外执行
DROP TABLESPACE xxx INCLUDING CONTENTS AND DATAFILES;，前提是该表空间没被其他用户使用 - 回收站（
RECYCLEBIN）里的分区表对象也会被一并清除，但不会触发任何级联逻辑
