oracle 12c通过异步全局索引维护优化drop/truncate分区性能：使用update indexes仅更新元数据，索引保持valid，实际清理延至后台job或手动触发（如dbms_part.cleanup_gidx），但仅适用于堆表，不支持对象表、域索引或sys用户对象。
oracle 12c 中没有 cascade 子句用于删除分区操作 —— 这是常见误解的根源。真正影响性能的是级联行为本身，而非某个叫 cascade 的语法开关。
ALTER TABLE ... DROP PARTITION 默认不带 CASCADE，但实际效果常被误认为“级联”
Oracle 的 DROP PARTITION 语句本身不支持 CASCADE 关键字（不像 DROP TABLE ... CASCADE CONSTRAINTS）。所谓“级联删除分区”其实是用户对两个独立机制的混淆：
- 外键约束上定义的
ON DELETE CASCADE：作用于行级删除，与分区 DDL 无关； - 分区 DDL 操作（如
DROP PARTITION）触发的全局索引维护逻辑：这才是真实影响性能的环节。
当你执行 ALTER TABLE sales DROP PARTITION p2024，真正耗时的不是“删分区”，而是后续对全局索引中指向该分区数据的索引条目的清理 —— 尤其在 12c 之前，这会直接让索引变为 UNUSABLE，必须重建。
12c 引入异步全局索引维护，但 UPDATE GLOBAL INDEXES 仍有隐性开销
在 12c 中，加上 UPDATE GLOBAL INDEXES 后，DDL 变成元数据操作，索引状态保持 VALID，看似“快了”。但代价是把工作推迟到后台：
- 孤立索引条目（orphan entries）仍存在，会轻微拖慢后续全索引扫描（如
INDEX FULL SCAN）； - 清理由
SYS.PMO_DEFERRED_GIDX_MAINT_JOB承担，默认每天凌晨 2 点运行 —— 如果你当天有多次分区操作，JOB 可能积压，导致延迟清理； - 手动触发
DBMS_PART.CLEANUP_GIDX能立刻清理，但它会阻塞 DML，且需ANALYZE INDEX ... VALIDATE STRUCTURE配合确认效果。
示例：一次 DROP PARTITION + UPDATE GLOBAL INDEXES 在 10GB 分区上可能秒级完成，但后台 JOB 清理可能持续数分钟，期间索引物理大小未变、统计信息未更新。
真正危险的“级联式影响”来自外键 + 分区组合
如果你在子表上建了外键引用父分区表的主键，并且子表没分区、也没建合适索引，那么即使只是删一个分区，也可能引发意外连锁反应：
-
DROP PARTITION不检查子表 —— 它只删父表数据，不会自动删子表关联行； - 但若子表有
ON DELETE CASCADE外键指向父表，则父表行删除（比如先DELETE FROM parent WHERE ...）会触发子表级联删除 —— 这和分区 DDL 完全无关，却常被混为一谈； - 更隐蔽的问题：某些 ETL 工具或 ORM 会在删分区前自动补全
DELETE语句，结果变成“先删行再删分区”，双重开销叠加。
验证方法：查 USER_CONSTRAINTS 中 CONSTRAINT_TYPE = 'R' 且 DELETE_RULE = 'CASCADE' 的记录，再比对子表是否建了 (parent_id) 索引 —— 没索引的 ON DELETE CASCADE 在子表大时会全表扫，比删分区本身还慢。
性能评估不能只看 DDL 时间，得盯住三处
别只用 SET TIMING ON 测 DROP PARTITION 耗时。真实瓶颈常藏在这三个地方：
-
V$SESSION_LONGOPS：查OPNAME LIKE '%index%'，确认后台 JOB 是否卡住； -
DBA_INDEXES.STATUS和DBA_IND_PARTITIONS.STATUS：确认索引是否真VALID，还是表面正常实则含大量 orphan； -
AWR报告中 “Segments by Logical Reads”：删完分区后如果某全局索引的逻辑读暴增，说明查询正在穿透无效条目。
最易被忽略的一点：UPDATE GLOBAL INDEXES 不解决统计信息陈旧问题。分区删掉后，DBMS_STATS.GATHER_TABLE_STATS 必须显式调用，否则优化器可能继续走错执行计划 —— 这种“慢”根本不会出现在 DDL 日志里。
