这篇文章主要为大家展示了“数据库中走索引删除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秒的优化案例”这篇文章的所有内容，感谢各位的阅读！相信大家都有了一定的了解，希望分享的内容对大家有所帮助，如果还想学习更多知识，欢迎关注亿速云行业资讯频道！
免责声明：本站发布的内容（图片、视频和文字）以原创、转载和分享为主，文章观点不代表本网站立场，如果涉及侵权请联系站长邮箱：is@yisu.com进行举报，并提供相关证据，一经查实，将立刻删除涉嫌侵权内容。
