oracle 12c 中不存在“级联分区”，实际应使用 reference partitioning：父表须为分区表且分区键属主键/唯一键，子表外键必须严格匹配该分区键列（类型、顺序、长度等），并显式声明 partition by reference(约束名)，否则建表报 ora-14035 或 ora-14650。
Oracle 12c 中没有“级联分区”这个功能，你真正需要的是 REFERENCE PARTITIONING（引用分区），它能让子表复用父表的分区逻辑，从而在 JOIN 时支持 PARTITION WISE JOIN，大幅减少数据搬运。但必须严格满足条件，否则建表失败或优化器直接忽略分区优势。
REFERENCE PARTITIONING 建表失败的三个硬性条件
建表语句里写 PARTITION BY REFERENCE 不等于就能成功——Oracle 会立刻报错，常见如 ORA-14035 或 ORA-14650。关键卡点有：
- 父表必须已是分区表，且分区键列必须是主键或唯一键的一部分（不能只是普通列）
- 子表外键必须**完全指向父表的分区键列**：列名、类型、长度、顺序、甚至 NLS 设置都得一致；比如父表按
order_dateRANGE 分区，子表外键就不能指向order_id - 子表建表时必须显式声明外键约束名，并在
PARTITION BY REFERENCE (fk_name)中精确引用该名字，拼错一个字母就失败
为什么 TRUNCATE PARTITION CASCADE 不生效？
即使引用分区建成功，ALTER TABLE parent TRUNCATE PARTITION p1 CASCADE 仍可能只清空父表、子表数据不动。原因很具体：
- 外键定义里缺少
ON DELETE CASCADE——这是CASCADE操作能下推到子表的强制前提 - 子表虽用了
PARTITION BY REFERENCE，但没加ON DELETE CASCADE，Oracle 就当它是普通外键，拒绝级联 - 父表分区被 TRUNCATE 后，子表对应分区若存在未提交事务或索引失效，也会中断级联流程
PARTITION WISE JOIN 为什么没出现在执行计划里？
两张表都按 sale_date RANGE 分区、JOIN 条件也写 o.sale_date = i.sale_date，但 EXPLAIN PLAN 里还是只有 HASH JOIN。真实瓶颈往往藏在这几处：
- 子表用了
GLOBAL INDEX而非LOCAL INDEX，优化器无法确认分区边界与数据分布的一致性 - 连接字段存在隐式转换：比如父表是
DATE，子表是TIMESTAMP，Oracle 自动转成TIMESTAMP，破坏了分区键直连 - 统计信息过期，特别是
DBA_TAB_STATISTICS中的NUM_ROWS差异过大，让优化器误判代价，主动放弃 PWJ - 分区边界不等价：父表按
VALUES LESS THAN (DATE'2025-04-01')，子表却用TO_DATE('01/04/2025','DD/MM/YYYY')，时区或 NLS 设置不同会导致边界值实际不等
最容易被忽略的分区对齐细节
即便所有 DDL 都正确，JOIN 性能仍上不去，大概率是因为物理层面没对齐。比如：
- 父表分区存储在多个表空间（
STORE IN (ts1, ts2, ts3)），但子表建表时没指定STORE IN，导致部分分区落在同一磁盘，IO 争用抵消并行优势 - 远程表同步到本地后建了引用分区，但本地复制表没按原表的相同粒度分区（比如原表按月，本地表按季度），
PARTITION WISE JOIN直接失效 -
EXCHANGE PARTITION后忘了收集子表统计信息，优化器基于旧统计估算错误，拒绝启用 PWJ
