數據庫中走索引刪除0條記錄卻要142秒的優化案例

這篇文章主要為大家展示了“數據庫中走索引刪除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秒的優化案例”這篇文章的所有內容，感謝各位的閱讀！相信大家都有了一定的了解，希望分享的內容對大家有所幫助，如果還想學習更多知識，歡迎關注億速云行業資訊頻道！