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

这篇文章主要为大家展示了“数据库中走索引删除0条记录却要142秒的优化案例”，内容简而易懂，条理清晰，希望能够帮助大家解决疑惑，下面让小编带领大家一起研究并学习一下“数据库中走索引删除0条记录却要142秒的优化案例”这篇文章吧。BI库上有个定时删除SQL，目的在于删除一个月之前的数据（即表中的数据只保留一个月）：delete from table1 t where t.update_date

按道理顶多是一天的数据，走索引应该是很快的；但事实上，每次却花了约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秒的优化案例”这篇文章的所有内容，感谢各位的阅读！相信大家都有了一定的了解，希望分享的内容对大家有所帮助，如果还想学习更多知识，欢迎关注云技术行业资讯频道！

按道理顶多是一天的数据，走索引应该是很快的；但事实上，每次却花了约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秒的优化案例”这篇文章的所有内容，感谢各位的阅读！相信大家都有了一定的了解，希望分享的内容对大家有所帮助，如果还想学习更多知识，欢迎关注云技术行业资讯频道！

相关推荐: 如何查看修改oracle归档日志路径

这篇文章将为大家详细讲解有关如何查看修改oracle归档日志路径，小编觉得挺实用的，因此分享给大家做个参考，希望大家阅读完这篇文章后可以有所收获。1.修改归档日志的格式默认格式是：“ %t_%s_%r.dbf”，我们尝试将格式修改为“%t_%s_%r.arch…