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

共计 2338 个字符，预计需要花费 6 分钟才能阅读完成。

这篇文章主要为大家展示了“数据库中走索引删除 0 条记录却要 142 秒的优化案例”，内容简而易懂，条理清晰，希望能够帮助大家解决疑惑，下面让丸趣 TV 小编带领大家一起研究并学习一下“数据库中走索引删除 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 秒的优化案例”这篇文章的所有内容，感谢各位的阅读！相信大家都有了一定的了解，希望分享的内容对大家有所帮助，如果还想学习更多知识，欢迎关注丸趣 TV 行业资讯频道！