分区表上建INVISIBLE索引前须避开ORA-01408报错，因Oracle禁止同列存在结构相同的索引；已有VISIBLE索引时应ALTER INDEX ... INVISIBLE切换而非新建，本地与全局索引可共存，TRUNCATE分区不使INVISIBLE索引失效但也不参与裁剪，其核心价值在于安全变更而非性能提升。
分区表上建INVISIBLE索引前必须避开ORA-01408重复索引报错
在分区表上直接对同一列加多个B树索引（哪怕一个VISIBLE、一个INVISIBLE）会触发ORA-01408，Oracle不允许同列存在结构相同的索引。这不是权限或语法问题，是内核级限制。
实操建议：
- 如果已有
VISIBLE索引，想测试其删除影响，直接用ALTER INDEX idx_name INVISIBLE切换，不要新建 - 若需并存两个逻辑索引（比如一个普通B树+一个位图），可显式指定类型：
CREATE BITMAP INDEX idx_bmp ON t(col) INVISIBLE - 本地分区索引（
LOCAL）和全局索引（GLOBAL）属于不同结构，可以共存于同一列，但要注意维护成本差异
TRUNCATE旧分区时，INVISIBLE索引不会失效但也不参与裁剪
12c+环境下，TRUNCATE PARTITION本身已支持异步全局索引维护，但INVISIBLE索引的特殊性在于：它物理存在、DML持续更新、全局索引状态保持VALID，但优化器默认完全忽略——所以既不会因分区删掉而变UNUSABLE，也不会在查询中被用于分区裁剪。
这意味着：
- 你可以在滚动窗口脚本里先
ALTER INDEX ... INVISIBLE，再执行TRUNCATE PARTITION，全程无索引失效风险 - 但如果某条SQL恰好依赖该索引的字段做范围过滤（如
WHERE order_date > ...），且没带分区键条件，执行计划仍会走全表扫描，不会“退化”去用这个隐身索引 -
optimizer_use_invisible_indexes=TRUE只在当前会话生效，不能作为长期运维配置，否则可能意外激活测试索引干扰生产计划
用INVISIBLE索引模拟“灰度下线”全局索引的完整流程
真实运维中，最怕的是全局索引重建耗时太久锁表，或TRUNCATE后发现某批报表SQL性能暴跌。INVISIBLE索引在这里不是替代方案，而是隔离验证层。
典型步骤：
- 查
dba_indexes确认目标全局索引状态：SELECT index_name, status, visibility FROM dba_indexes WHERE table_name = 'SALES' AND index_type = 'NORMAL' - 会话级开启隐形索引可见：
ALTER SESSION SET optimizer_use_invisible_indexes = TRUE，仅用于验证 - 执行关键SQL，对比
EXPLAIN PLAN中是否命中该索引、ROWS预估是否合理 - 若验证通过，再执行
ALTER INDEX idx_global INVISIBLE；若失败，立刻ALTER INDEX ... VISIBLE回滚，无需重建
注意：INVISIBLE不改变索引段的物理位置或统计信息，所以DBMS_STATS.GATHER_INDEX_STATS仍需定期跑，否则验证结果失真。
本地分区索引设为INVISIBLE后，分区裁剪是否还生效？
不会。本地分区索引（LOCAL）的裁剪能力依赖优化器识别“索引分区与表分区严格对齐”，一旦设为INVISIBLE，优化器连索引是否存在都不感知，自然跳过整个裁剪逻辑，降级为全分区扫描。
所以：
- 不要对核心查询路径上的本地索引轻易设
INVISIBLE，尤其当WHERE条件含分区键时 - 如果只是想停用某个本地索引但保留结构，更稳妥的做法是
ALTER INDEX ... UNUSABLE+ 后续REBUILD PARTITION，虽然重建慢，但至少裁剪行为可控 - 真正适合
INVISIBLE的，是那些跨分区聚合、非分区键过滤、或仅被夜间作业调用的全局索引
INVISIBLE索引的价值不在“让查询变快”，而在“让变更不翻车”——它把索引生命周期里的高危操作（删、改、重建）拆成了可观察、可回退、不影响他人执行计划的原子步骤。但凡忘了查visibility字段或误开optimizer_use_invisible_indexes，就等于在生产环境埋了个静默开关。
