局部索引在 DROP PARTITION 后失效是因为对应索引分区被物理删除但状态仍显示 USABLE，查询时触发 ORA-01502 错误；TRUNCATE PARTITION 则显式将索引分区置为 UNUSABLE；12.2+ 可用 UPDATE INDEXES 自动重建（仅限 DROP/SPLIT），否则需手动 REBUILD PARTITION。
局部索引在 DROP PARTITION 后为什么失效？
oracle 局部索引（local）默认是 usable 的，但一旦执行 drop partition，对应分区的索引段会被物理删除，而索引整体状态仍显示 usable——这容易让人误以为“还能用”。实际查询涉及该分区键范围时会报错：ora-01502: index 'xxx' or partition of such index is in unusable state。根本原因不是 oracle 忘了重建，而是它把“可用性”判定交给了你：局部索引的每个分区独立维护，删分区不等于删索引分区，但索引分区不会自动重建。
-
DROP PARTITION不触发索引重建，只移除表分区和其对应的索引分区（如果存在）；若索引分区已不存在，状态字段不会自动更新为UNUSABLE，但访问路径会失败 - 真正生效的是
ALTER TABLE ... DROP PARTITION ... UPDATE INDEXES语法，它会同步重建受影响的局部索引分区（需 12cR2+，且仅对LOCAL索引有效） - 11g 及更早版本必须手动
ALTER INDEX ... REBUILD PARTITION，否则查询可能静默走全表扫描或直接报错
TRUNCATE PARTITION 对局部索引的影响与修复方式
TRUNCATE PARTITION 比 DROP 更隐蔽：它清空数据但保留结构，局部索引对应分区的状态会变成 UNUSABLE（Oracle 明确标记），但这个变化不会阻塞 DML，只会在后续 SELECT / INSERT 中暴露问题。关键点在于：它不重建、不重命名、不迁移，只是把索引分区“作废”了。
- 执行后立即查
USER_IND_PARTITIONS.STATUS，能看到对应分区状态为UNUSABLE - 不能靠
UPDATE INDEXES修复TRUNCATE——该子句只对DROP和SPLIT有效 - 必须显式重建：
ALTER INDEX idx_name REBUILD PARTITION p_name；若想批量处理，可用动态 SQL 构造语句，但注意并发 DML 可能被阻塞 - 重建期间该分区索引不可用，但其他分区照常工作——这是局部索引的优势，也是你得自己盯住每个分区的原因
如何让局部索引随分区操作“自动”重建？
Oracle 没有全局开关让局部索引“自动重建”，所谓“自动”只能靠语法层面的显式委托或脚本兜底。最接近自动的方式是用 UPDATE INDEXES 子句，但它有硬性限制：
- 仅适用于
ALTER TABLE ... DROP PARTITION和SPLIT PARTITION，不支持TRUNCATE或EXCHANGE - 要求数据库版本 ≥ 12.2；11g/12.1 即使写了也报错
ORA-00922: missing or invalid option - 必须确保索引本身是
LOCAL，且未指定UNUSABLE属性；如果建索引时用了NOLOGGING，重建过程也不会继承该属性 - 示例：
ALTER TABLE sales DROP PARTITION p_2023_q1 UPDATE INDEXES;—— 这条会重建所有依赖该分区的局部索引分区
容易被忽略的兼容性与性能陷阱
很多人以为加了 UPDATE INDEXES 就一劳永逸，结果在生产环境出问题。核心矛盾在于：重建不是零成本操作，而 Oracle 不会告诉你它悄悄花了多久。
- 重建局部索引分区会持有
TM（表级）和TX（事务级）锁，时间取决于分区数据量；大分区重建可能卡住应用写入 - 12.2+ 的
UPDATE INDEXES在主表分区操作提交前完成重建，意味着整个 DDL 是原子性的，失败则全部回滚——这点比手动 rebuild 更安全，但也更难中断 - 如果表有多个局部索引，
UPDATE INDEXES会逐个重建，无法并行控制；想加速只能提前用PARALLEL提示建索引，但重建时并行度由系统决定 - 监控要点：别只看
USER_IND_PARTITIONS.STATUS，还要查V$SESSION_LONGOPS里是否有Index Coalesce或Rebuild Index类型的长操作
局部索引的“自动”永远是个幻觉。你得清楚每条 DDL 背后 Oracle 真正做了什么，而不是依赖状态字段的表面值。尤其当分区策略变复杂（比如二级分区 + 局部索引嵌套），一个 TRUNCATE 就可能让十几个索引分区集体失能，而错误日志里只有一行模糊的 ORA-01502。
