共計 2338 個字符，預(yù)計需要花費 6 分鐘才能閱讀完成。
這篇文章主要為大家展示了“數(shù)據(jù)庫中走索引刪除 0 條記錄卻要 142 秒的優(yōu)化案例”，內(nèi)容簡而易懂，條理清晰，希望能夠幫助大家解決疑惑，下面讓丸趣 TV 小編帶領(lǐng)大家一起研究并學(xué)習(xí)一下“數(shù)據(jù)庫中走索引刪除 0 條記錄卻要 142 秒的優(yōu)化案例”這篇文章吧。
BI 庫上有個定時刪除 SQL，目的在于刪除一個月之前的數(shù)據(jù)（即表中的數(shù)據(jù)只保留一個月）：
delete from table1 t where t.update_date add_months(trunc(sysdate),-1)
按道理頂多是一天的數(shù)據(jù)，走索引應(yīng)該是很快的；但事實上，每次卻花了約 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) |
=========================================================================================================================================================================
從執(zhí)行計劃看，的確走了索引，但又沒有命中數(shù)據(jù)（原因是這個調(diào)度并不是一天只跑一次，只有第一次才會有數(shù)據(jù)），問題是物理讀有 1 個 G，這個很不正常；
所以做了一個測試：select min(update_time) from table1 ;
執(zhí)行計劃也沒錯：
————————————————————————————————
| 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 的物理讀；
為什么會有這么多的物理讀呢？會不會是行預(yù)取？應(yīng)該不是，如果是行預(yù)取用于緩存，那第二次跑應(yīng)該沒有物理讀了。
很有可能是索引有問題了，至于什么問題懶得去細(xì)究了，先在線重建再說；
重建完后，果然正常了，各種查詢，都是秒出；
以上是“數(shù)據(jù)庫中走索引刪除 0 條記錄卻要 142 秒的優(yōu)化案例”這篇文章的所有內(nèi)容，感謝各位的閱讀！相信大家都有了一定的了解，希望分享的內(nèi)容對大家有所幫助，如果還想學(xué)習(xí)更多知識，歡迎關(guān)注丸趣 TV 行業(yè)資訊頻道！
