数据库中走索引删除0条记录却要142秒的优化案例

发布时间:2021-11-09 13:40:43 作者:小新
来源:亿速云 阅读:138

这篇文章主要为大家展示了“数据库中走索引删除0条记录却要142秒的优化案例”,内容简而易懂,条理清晰,希望能够帮助大家解决疑惑,下面让小编带领大家一起研究并学习一下“数据库中走索引删除0条记录却要142秒的优化案例”这篇文章吧。

 BI库上有个定时删除SQL,目的在于删除一个月之前的数据(即表中的数据只保留一个月):

 delete from table1 t where t.update_date<add_months(trunc(sysdate),-1)

 按道理顶多是一天的数据,走索引应该是很快的;但事实上,每次却花了约142秒:

SQL Plan Monitoring Details (Plan Hash Value=1646136989)

=========================================================================================================================================================================

| Id |      Operation      |          Name           |  Rows   | Cost |   Time    | Start  | Execs |   Rows   | Read | Read  | Activity |        Activity Detail        |

|    |                     |                         | (Estim) |      | Active(s) | Active |       | (Actual) | Reqs | Bytes |   (%)    |          (# samples)          |

=========================================================================================================================================================================

|  0 | DELETE STATEMENT    |                         |         |      |           |        |     1 |          |      |       |          |                               |

|  1 |   DELETE            | TABLE1                  |         |      |           |        |     1 |          |      |       |          |                               |

|  2 |    INDEX RANGE SCAN | IDX_TABLE1_UPDATE_DATE  |    303K | 1030 |       143 |     +0 |     1 |        0 | 162K |   1GB |   100.00 | Cpu (1)                       |

|    |                     |                         |         |      |           |        |       |          |      |       |          | db file sequential read (141) |

=========================================================================================================================================================================

从执行计划看,的确走了索引,但又没有命中数据(原因是这个调度并不是一天只跑一次,只有第一次才会有数据),问题是物理读有1个G,这个很不正常;

所以做了一个测试:select min(update_time) from table1 ; 

执行计划也没错:

------------------------------------------------------------------------------------------------

| Id | Operation                    | Name                    | Rows | Bytes | Cost | Time     |

------------------------------------------------------------------------------------------------

|  0 | SELECT STATEMENT             |                         |    1 |    11 |    3 | 00:00:01 |

|  1 |   SORT AGGREGATE             |                         |    1 |    11 |      |          |

|  2 |    INDEX FULL SCAN (MIN/MAX) | IDX_TABLE1_UPDATE_DATE  |    1 |    11 |    3 | 00:00:01 |

------------------------------------------------------------------------------------------------

但同样跑了很久,1G的物理读;

为什么会有这么多的物理读呢?会不会是行预取?应该不是,如果是行预取用于缓存,那第二次跑应该没有物理读了。

很有可能是索引有问题了,至于什么问题懒得去细究了,先在线重建再说;

重建完后,果然正常了,各种查询,都是秒出;

以上是“数据库中走索引删除0条记录却要142秒的优化案例”这篇文章的所有内容,感谢各位的阅读!相信大家都有了一定的了解,希望分享的内容对大家有所帮助,如果还想学习更多知识,欢迎关注亿速云行业资讯频道!

推荐阅读:
  1. SQL优化案例分享--联合索引
  2. 怎样优化MySql数据库的索引?

免责声明:本站发布的内容(图片、视频和文字)以原创、转载和分享为主,文章观点不代表本网站立场,如果涉及侵权请联系站长邮箱:is@yisu.com进行举报,并提供相关证据,一经查实,将立刻删除涉嫌侵权内容。

数据库

上一篇:MyBatis-Plus如何实现字段自动填充功能

下一篇:数据库中大表删除字段慢的原因有哪些

相关阅读

您好,登录后才能下订单哦!

密码登录
登录注册
其他方式登录
点击 登录注册 即表示同意《亿速云用户服务条款》