關於索引過度的表的Oracle更新聲明

我在Oracle中使用簡單的更新語句掙扎。更新本身並沒有永遠改變，但表格已經大量增加，現在的表現無法接受。這裏是低谷值： 70列 27個索引（我在任何情況下都不允許減少） 50M行更新聲明只是打到一個表。關於索引過度的表的Oracle更新聲明

Update語句：

update TABLE_NAME 
    set NAME = 'User input string', 
    NO = NO, 
    PLANNED_START_DATE = TO_DATE('3/2/2016','dd/mm/yyyy'), 
    PLANNED_END_DATE = TO_DATE('3/2/2016','dd/mm/yyyy'), 
    WHERE ID = 999999 /*pk on the table*/

執行計劃：

================== 
     Plan hash value: 2165476569 

    ----------------------------------------------------------------------------------------------- 
| Id | Operation     | Name   | Rows | Bytes | Cost (%CPU)| Time  | 
----------------------------------------------------------------------------------------------- 
| 0 | UPDATE STATEMENT    |    |  1 | 245 |  1 (0)| 00:00:01 | 
| 1 | UPDATE      | TABLE_NAME  |  |  |   |   | 
| 2 | TABLE ACCESS BY INDEX ROWID| TABLE_NAME  |  1 | 245 |  1 (0)| 00:00:01 | 
|* 3 | INDEX UNIQUE SCAN   | PK_INDEX  |  1 |  |  1 (0)| 00:00:01 | 
-----------------------------------------------------------------------------------------------  
    Predicate Information (identified by operation id): 
    --------------------------------------------------- 

     3 - access("ID"=35133238) 

==================================================

update語句起源於一個C＃應用程序，但我可以自由地改變說法存在。 Select語句仍然表現良好，這要歸功於所有索引，但正如我所看到的那樣，更新到底是什麼問題 - 它必須更新所有索引。我們已獲得分區許可，但此表未分區。

如何在不更改表或其索引的情況下提高此更新語句的性能？

來源

2016-02-04 Tara

ID列是主鍵中唯一的列嗎？如果是這樣，PK_INDEX僅在ID列中索引，還是在其中還有其他列？從所假設的主鍵中選擇單個值時，我對188的基數感到驚訝。另外，您要更新的列有多少個索引？ – Boneist

另外，您的統計數據是否在表格及其索引上保持最新？ – Boneist

感謝您的參與 - 我已經包含了來自不同系統的解釋計劃。我已經在上面編輯過，包括正確的解釋計劃輸出。 @Aleksey這也是爲什麼188行顯示（它在開發系統中不是唯一值） – Tara

你確定列ID是主鍵嗎？並且是基於唯一索引的主鍵？因爲在這種情況下，CBO將使用INDEX UNIQUE SCAN。在您的計劃中，CBO預計使用過濾器ID（主要kay）=值的188行，並使用INDEX RANGE SCAN

來源

2016-02-04 17:33:56 SkyWalker

關於索引過度的表的Oracle更新聲明

回答

相關問題