大家好，又见面了，我是你们的朋友全栈君。如果您正在找激活码,请点击查看最新教程,关注关注公众号 “全栈程序员社区” 获取激活教程,可能之前旧版本教程已经失效.最新Idea2022.1教程亲测有效,一键激活。
Jetbrains全系列IDE使用 1年只要46元 售后保障 童叟无欺
1.背景概述
近期应用升级上线过程中，存在删除业务表索引的变更操作，且因删除索引导致次日业务高峰时期，数据库响应缓慢的情况，经定位是缺失索引导致。与用户沟通，虽然变更中删除索引的需求很少，但也存在此类需求。
本文从数据库层面，旨在尽可能避免类似问题发生，制定删除索引的变更规范。
2.索引删除规范
若确认需要做索引删除，可以使用Oracle提供的两个功能特性协助判断删除索引是否会有隐患。
2.1 增加索引监控
将计划要删除的索引经过至少一个业务周期(具体业务确认业务周期为多久，注意要考虑到跑批场景)的监控，如果整个业务周期，该索引一直没有被使用过则可以考虑删除。
演示案例：
create table T as select * from dba_objects;
create index IDX_T_01 on T(object_id);
假设要删除的索引名称是IDX_T_01，使用下面语句开启该索引的监控。
alter index jingyu.IDX_T_01 monitoring usage;
索引是否使用到，会在具体业务schema下的v$object_usage视图中体现(具体观察USED这一列的值，如果是NO，说明自监控以来该索引从未使用过)
conn jingyu/jingyu
col index_name for a30
col table_name for a30
col START_MONITORING for a30
col END_MONITORING for a30
set lines 180
select * from v$object_usage;
INDEX_NAME TABLE_NAME MONITO USED START_MONITORING END_MONITORING
———- ———- —— —— —————————— ——————————
IDX_T_01 T YES NO 07/22/2020 14:15:18
如果有人/应用执行过用到该索引的语句，比如：
select object_id from t where object_id = 3;
此时再观察USED这一列的值，已经变为yes，说明自监控以来该索引有被使用过，就不能被轻易删除：
INDEX_NAME TABLE_NAME MONITO USED START_MONITORING END_MONITORING
———- ———- —— —— —————————— ——————————
IDX_T_01 T YES YES 07/22/2020 14:15:18
如果不再需要监控该索引，可以这样取消该索引的监控：
alter index jingyu.IDX_T_01 nomonitoring usage;
INDEX_NAME TABLE_NAME MONITO USED START_MONITORING END_MONITORING
———- ———- —— —— —————————— ——————————
IDX_T_01 T NO NO 07/22/2020 14:30:30 07/22/2020 14:30:58
优点：简单，能有效监控整个业务周期内索引是否被使用到，如果没有被使用则可以放心删除。
缺点：只能判断是否被使用到，不能判断索引使用频率。
2.2 将删除索引先修改为不可见
将计划要删除的索引设置为不可见(invisible)，然后经历至少一个业务周期(具体业务确认业务周期为多久，注意要考虑到跑批场景)的观察，确认没有影响，则可以考虑彻底删除。
设置索引IDX_T_01不可见：
alter index jingyu.IDX_T_01 invisible;
执行演示SQL发现已经是全表扫：
explain plan for select object_id from t where object_id = 3;
select * from table(dbms_xplan.display());
PLAN_TABLE_OUTPUT
—————————————————————————————————-
Plan hash value: 1601196873
————————————————————————–
| Id | Operation | Name | Rows | Bytes | Cost (%CPU)| Time |
————————————————————————–
| 0 | SELECT STATEMENT | | 11 | 143 | 283 (2)| 00:00:04 |
|* 1 | TABLE ACCESS FULL| T | 11 | 143 | 283 (2)| 00:00:04 |
————————————————————————–
恢复索引IDX_T_01可见：
alter index jingyu.IDX_T_01 visible;
执行演示SQL发现又恢复了索引访问，无需重建：
explain plan for select object_id from t where object_id = 3;
select * from table(dbms_xplan.display());
PLAN_TABLE_OUTPUT
—————————————————————————————————-
Plan hash value: 2968633466
—————————————————————————–
| Id | Operation | Name | Rows | Bytes | Cost (%CPU)| Time |
—————————————————————————–
| 0 | SELECT STATEMENT | | 1 | 13 | 1 (0)| 00:00:01 |
|* 1 | INDEX RANGE SCAN| IDX_T_01 | 1 | 13 | 1 (0)| 00:00:01 |
—————————————————————————–
优点：因为invisible索引只是让优化器不可见，索引段中的数据依然存在且DML操作也会维护这些invisible的索引，所以回退(直接修改该索引为可见)非常方便。
缺点：如果删除索引是为了更快加载数据，那么设置索引invisible期间，并不会提升效率。另外应用会话如果有设置OPTIMIZER_USE_INVISIBLE_INDEXES=TRUE的参数，也会用到invisible索引，而这可能会造成误判，需要特别注意。
3.根本解决方案及建议
删除索引的情景一般是考虑到索引数量过多，从而导致索引维护成本和空间使用成本增加。一般原则是首先评估删除冗余索引，比如某张表同时有两个索引，索引A是c1列，索引B是c1，c2两列的复合索引，则一般可以选择删除索引A；但需要注意，如果索引B是c2和c1列的复合索引，就通常不可以删除索引A。其次，对其他计划删除的索引可以按照上文的规范来评估和操作。
发布者：全栈程序员-站长，转载请注明出处：https://javaforall.net/197039.html原文链接：https://javaforall.net
