近期应用升级上线过程中，存在删除业务表索引的变更操作，且因删除索引导致次日业务高峰时期，数据库响应缓慢的情况，经定位是缺失索引导致。与用户沟通，虽然变更中删除索引的需求很少，但也存在此类需求。 本文从数据库层面，旨在尽可能避免类似问题发生，制定删除索引的变更规范。

若确认需要做索引删除，可以使用Oracle提供的两个功能特性协助判断删除索引是否会有隐患。

2.1 增加索引监控

将计划要删除的索引经过至少一个业务周期（具体业务确认业务周期为多久，注意要考虑到跑批场景）的监控，如果整个业务周期，该索引一直没有被使用过则可以考虑删除。 演示案例：

假设要删除的索引名称是IDX_T_01，使用下面语句开启该索引的监控。

索引是否使用到，会在具体业务schema下的v$object_usage视图中体现（具体观察USED这一列的值，如果是NO，说明自监控以来该索引从未使用过）

如果有人/应用执行过用到该索引的语句，比如：

此时再观察USED这一列的值，已经变为yes，说明自监控以来该索引有被使用过，就不能被轻易删除：

如果不再需要监控该索引，可以这样取消该索引的监控：

优点：简单，能有效监控整个业务周期内索引是否被使用到，如果没有被使用则可以放心删除。 缺点：只能判断是否被使用到，不能判断索引使用频率。

2.2 将删除索引先修改为不可见

将计划要删除的索引设置为不可见（invisible），然后经历至少一个业务周期（具体业务确认业务周期为多久，注意要考虑到跑批场景）的观察，确认没有影响，则可以考虑彻底删除。

设置索引IDX_T_01不可见：

执行演示SQL发现已经是全表扫：

恢复索引IDX_T_01可见：

执行演示SQL发现又恢复了索引访问，无需重建：

优点：因为invisible索引只是让优化器不可见，索引段中的数据依然存在且DML操作也会维护这些invisible的索引，所以回退（直接修改该索引为可见）非常方便。 缺点：如果删除索引是为了更快加载数据，那么设置索引invisible期间，并不会提升效率。另外应用会话如果有设置OPTIMIZER_USE_INVISIBLE_INDEXES=TRUE的参数，也会用到invisible索引，而这可能会造成误判，需要特别注意。

删除索引的情景一般是考虑到索引数量过多，从而导致索引维护成本和空间使用成本增加。一般原则是首先评估删除冗余索引，比如某张表同时有两个索引，索引A是c1列，索引B是c1，c2两列的复合索引，则一般可以选择删除索引A；但需要注意，如果索引B是c2和c1列的复合索引，就通常不可以删除索引A。其次，对其他计划删除的索引可以按照上文的规范来评估和操作。