Oracle本地分区索引不自动同步表分区操作是因设计上采用保守策略，避免意外丢失数据；DROP、MERGE、SPLIT、EXCHANGE分区等DDL需显式加UPDATE INDEXES才成功，否则报ORA-14048；加该子句仅保证索引结构同步，但可能置为UNUSABLE状态，须手动REBUILD。
Oracle 本地分区索引为什么不会自动跟随表分区操作？
因为 local index 本身设计就是“绑定”到表分区的，但它的生命周期并不自动同步——比如你用 alter table ... split partition，索引分区会跟着拆，但 drop partition 默认会失败，除非显式加 update indexes。这不是 bug，是 oracle 的保守策略：避免意外丢失索引数据。
哪些 DDL 操作必须加 UPDATE INDEXES 才能成功？
常见报错是 ORA-14048：“partition maintenance operation may not be combined with other operations”，本质是没告诉 Oracle “连带管管索引”。以下操作不加 UPDATE INDEXES 就会失败：
ALTER TABLE ... DROP PARTITIONALTER TABLE ... MERGE PARTITIONS-
ALTER TABLE ... SPLIT PARTITION（虽通常能过，但不加可能引发索引不可用） -
ALTER TABLE ... EXCHANGE PARTITION（尤其和非分区表交换时）
UPDATE INDEXES 不是万能的：它只保结构，不保可用性
加了 UPDATE INDEXES 后，索引分区确实会跟着建/删/重组，但注意两点：
- 如果原分区里有大量数据，
SPLIT或MERGE可能导致对应索引分区进入UNUSABLE状态（查USER_INDEXES.STATUS可确认） -
UNUSABLE索引不会报错，但查询走不到，需要手动ALTER INDEX ... REBUILD PARTITION - 全局索引（
GLOBAL INDEX）加UPDATE INDEXES会重建整个索引，代价极大，本地索引才真正受益
如何验证本地索引是否真“跟上了”表分区变化？
别只信 DDL 成功，得查元数据：
- 对比
USER_TAB_PARTITIONS和USER_IND_PARTITIONS的PARTITION_NAME和数量是否一致 - 检查
USER_IND_PARTITIONS.STATUS是否全为USABLE - 执行
SELECT COUNT(*) FROM TABLE_NAME PARTITION (p_name)和对应索引分区的SELECT COUNT(*) FROM INDEX_NAME PARTITION (p_name)（需用DBMS_METADATA或分区键推导）
最常被忽略的是状态检查——很多问题不是索引没建，而是建了但 UNUSABLE 了，查询静默退化成全表扫描。
