建议增加安全删除索引的语法

建议与反馈 产品调研&需求&建议
, ,
#1

问题背景

https://open.oceanbase.com/course/detail/10665

image
image717×395 66.6 KB

索引使用的建议

索引修改流程为:新建索引时,必须确认新索引创建完成(即新索引已经生效),并确保旧索引不 会被使用后,再删除旧索引。

by the way: 这条建议,有点儿像高考前建议大家带好准考证。虽然看似简单且容易理解,但是 在蚂蚁集团内部,每年都会有个别同学在新索引还没建好时,就把旧索引给删了,然后造成支付宝 在某个业务上一段时间处于不可用状态,产生大量资损,最后不得不处罚几个DBA 来平息民愤。 希望各位 OceanBase 社区版的用户,在创建索引时,千万不要犯这个低级且可能会产生重大影响 的错误!

建议

蚂蚁使用OB最久，管理最规范，既然这个问题在蚂蚁都无法杜绝，是不是可以在产品层面优化一下。建议如下：

  1. 增加安全删除索引语法 ，比如,alter table tab_name drop index index_name safe; 在执行后，数据库会自行查找dba_index_usage来判断是否可以安全删除 ，当然安全的标准阈值，也可以有配套的参数来控制。

  2. 在满足以上功能后，增加参数控制是否禁止无safe的索引删除SQL。 比如SQL，无safe时，直接禁止执行。

  3. 在OCP上增加索引使用情况的巡检页。

  4. 增加租房、用户未使用索引数量超阈值的告警。提醒DBA删除无用索引。

3 个赞
#2

这种控制不了吧，你加的新索引和老索引都不是一个名，他怎么知道不允许删除哪个索引。很奇怪吧。
还有他在新建索引中，也根本删不掉老的索引，因为有锁，即使不报错后面执行也是顺序先加在删的。
正常操作索引正常的都是先加，（如果有隐藏可以隐藏），最后在删。
如果ddl能加索引的时候指定删除索引，反而这种好吧，比如：
alter table tab_name add index idx_xxx(col1,col2) , drop index index_name;

但是如果在这个语句之前先执行删索引还是不行。 出问题的基本都是这种场景吧，这种还是看人或者流程卡控吧。大部分这种执行都是开发提交的先删后加，正常dba优化sql不会这样操作。

增加监控使用率，也只是一段时间，对于月度年度使用的索引，一段时间时间监控不到也不代表他不使用。只是供DBA参考。

#3

基于dba_index_usage判断，比如近7天有使用记录的索引就不可以删除，执行会报错，如果没有使用，则正常执行完成

#4

解决的是误删当前在用索引的问题，有是否新建索引没关系。

#5

您的说法是对的，现在大家也都是这么做的。但是问题的，有的人可能会“不正常操作”，而且不正常操作这个事即使在蚂蚁也没有杜绝掉。

现在是否正常操作取决于人，没系统卡控。

我的需求要解决的是即使人为的"不正常操作"了,也能够阻止

#6

如前回答，目前人或者流程都没有卡控好

#7

正常没人会专门删除索引，他的场景是先删在加的场景出问题的，如果本身没有索引出问题那是另外的场景。
优化sql，他是必须要删除索引，即使你有使用，也要删除的，就比如他这种异常的先删在加的，正常步骤就是要先加在删，他还是要删。
不用回我了，谢谢。

#8

这个问题是有特殊背景的。

OB 0.x 版本的索引还需要通过一次每日合并才能生效，是 T+1，唯一索引要两次每日合并生效，是 T+2。

OB 1.x 也没支持索引实时生效，索引会立即返回创建成功，实际还在后台慢慢创建，可能让 DBA 误以为已经生效了。估计是因为创建索引的耗时不可控，不想让用户的 session 卡死，所以是异步生效。

蚂蚁内部很多业务还都是 1.x 版本，所以比较容易出问题。

后来从 2.0 版本开始，发现容易导致帖子里的问题，就又改回同步生效了。

蚂蚁外部的用户绝大多数都没有机会接触 1.x 版本的 OceanBase，如果索引同步生效还能搞出问题，那就真不是数据库的责任了，属于 DBA 自身需要避免的误操作。

蚂蚁内部业务最近也都开始升级数据库版本了。

#9

alter table t1 alter index idx_name visible;
alter table t1 alter index idx_name invisible;

这样方式，能否缓解下你的问题。索引先引藏几天，没问题了删除索引。有问题的话秒回来。

#10

这个需求解决的是“非正常”、“人为失误“风险。 您提的方法非常好，但是需要人来保障。

说一些可能发生问题的情况：

1.如果这个人一晚上就做这一个DDL，我相信大概是没问题的。 但是如果连续加班搞几晚，每天晚上一堆的DDL，很可能就不会细看这个DDL长什么样了。
2. 这个SQL是研发写的。但执行是DBA。 大部分时候研发是比较负责，写的没问题，但某一天研发让新来的菜鸟研发写了SQL，菜鸟研发可能不知道这些风险。负责交付的研发也没有审核， DBA在执行的时候出于对研发个人长期的信任，可能压根就没看SQL内容。

说一个相似的问题，我们DBA只要有足够的责任心，手搓运维肯定也不会出问题。但是为什么我们要做OCP以及其他的标准化运维，除了提效也是为了保障操作的标准性，而且官网上我看大部分情况下也是推荐在OCP上操作。

所以我的需求并不是 ”有什么办法让这个事正常执行“ ，而是” 有什么手段能让这个事不正常的情况下也无法执行“

#11

学习了。

您说的这情况，我理解为容易有歧义复杂的一种情况，

正常情况下，风险点DBA应该掌握，如果DBA完全掌握这个特点，也不会出现这个问题。 但其实我们要面对的风险点很多，难免会有疏忽。

所以我的问题是仍然是要解决非正常情况的问题。针对加减索引，仍然会有其他情况误删掉正在使用的索引。

#12

很有必要

#13

这玩意，咋能用数据库来评估你能不能删除

#14

一起看看

#15

dba_index_usage
https://www.oceanbase.com/docs/common-oceanbase-database-cn-1000000004477267

image
image1008×95 5.67 KB

image
image1072×55 3.53 KB

#16

删索引比较危险