删除数据库索引的正确姿势

有时候发现你之前创建的索引后来你用不上了，于是为了节省空间，降低优化器在选择执行计划时候的成本。我们会选择删除这个索引。

但是因为业务场景比较多，又不是所有代码都是一个人写的。所以直接drop索引可能导致意想不到的后果，ps，之前订单表索引失效就是血的教训，不过那次是由于没有及时收集统计信息。但也充分证明了索引的重要性和严重影响。

所以如何正确的删除你觉得不要用的索引，以客户表客户编码索引为例

1.alter index IDX_BASEDATA_FCUSTNUMBERinvisible;--让索引不可见，没有实际删除，但是优化器不会使用该索引

观察生产环境两三周吧。这个时间没有标准啦

2.没有影响。drop index IDX_BASEDATA_FCUSTNUMBER;--实际删除

有影响。alterindex IDX_BASEDATA_FCUSTNUMBER visible;--让索引可见，非常迅速且不会锁表

问，为什么不直接drop发现有影响再重建。

答，重建可能导致锁表或者锁分区，影响系统并发，严重的可能导致应用停机

问，为什么不采用非独占方式创建和删除索引以免造成上述影响。

答：createindex online和dropindex online的确可以解决锁表和避免造成长事务。但是使用也是有一些限制条件的。例如，使用online语法事务隔离级别要为（dirty read），online语法不锁表其实是等待表操作，如果表在操作create index online就暂停等待。