DELETE PARTITION 后全局索引变 INVALID 是 Oracle 默认行为，因删除分区可能导致索引指向无效数据块，故自动置为 INVALID 以保障一致性；需显式重建或使用 UPDATE GLOBAL INDEXES 子句维护。
DELETE PARTITION 后全局索引变 INVALID？不是删错了，是 Oracle 默认行为
oracle 执行 alter table ... drop partition 时，如果表上有全局索引（global index），该索引会自动进入 invalid 状态——这不是 bug，是设计如此。因为分区删除可能让索引中指向已不存在数据块的条目失效，oracle 不敢假设一致性，直接停用索引以避免查询出错。
常见错误现象：ORA-01502: index 'XXX' or partition of such index is in unusable state，执行 DML 或 SELECT 时突然报这个错，往往是因为之前只顾着删分区，没管索引。
- 必须显式重建或维护全局索引，不能依赖自动修复
-
DROP PARTITION本身不带索引维护选项；想避免失效，得加UPDATE GLOBAL INDEXES子句（但代价高，会锁表、阻塞写入） - 若业务允许短时间不可用，更常用的是先
UNUSABLE再重建，比UPDATE GLOBAL INDEXES快得多
重建全局索引：BUILD UNUSABLE + REBUILD 是最稳的组合
直接 ALTER INDEX ... REBUILD 看似简单，但如果索引当前是 VALID，重建过程会全程锁定索引，DML 可能被卡住；而如果已是 INVALID，Oracle 有时会拒绝重建，报 ORA-01408: column list already indexed 类似误导性错误。
正确做法是分两步走，明确控制状态：
- 先执行
ALTER INDEX idx_name UNUSABLE—— 这步极快，几乎不锁表，把索引主动置为不可用态 - 再执行
ALTER INDEX idx_name REBUILD—— 此时重建逻辑清晰，不会因残留状态报错 - 如需指定表空间或并行度：
REBUILD TABLESPACE ts_name PARALLEL 4
注意：REBUILD 默认不记录日志（NOLOGGING），如果归档/备库有要求，记得加 LOGGING。
用 UPDATE GLOBAL INDEXES？小心锁表和性能雪崩
在 DROP PARTITION 语句末尾加上 UPDATE GLOBAL INDEXES，确实能保持索引始终 VALID，但背后代价常被低估。
- 它会同步更新**所有**全局索引条目，扫描整个分区数据来修正叶节点指针——等价于对每个全局索引做一次全量维护
- 锁粒度是整张表，期间所有 DML（包括 INSERT/UPDATE/DELETE）都会被阻塞
- 如果分区大、全局索引多（比如 5+ 个），操作可能持续几十分钟，DBA 收到告警才反应过来
适用场景仅限：小分区（UPDATE GLOBAL INDEXES。
分区键值还在索引里？DROP PARTITION 不清理全局索引内容
这是最容易被忽略的底层事实：DROP PARTITION 只删数据段和本地索引，**不触碰全局索引的数据块**。那些原本指向该分区的索引条目，不会自动删除或标记为“过期”，而是滞留在索引结构中，直到你重建。
所以即使索引状态是 VALID（比如用了 UPDATE GLOBAL INDEXES），查询时仍可能扫到残留条目，触发 ORA-01502 或返回空结果——因为对应数据行已物理消失。
- 验证方式：
SELECT index_name, status FROM user_indexes WHERE table_name = 'TBL_NAME'; - 查残留条目：
ANALYZE INDEX idx_name VALIDATE STRUCTURE;后查index_stats表的DEL_LF_ROWS - 真正安全的做法，永远是以重建为终点，而不是只看
STATUS = VALID
重建不是锦上添花，是闭环动作。漏掉这步，历史分区删得再干净，全局索引也还是个半残状态。
