我在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
+0
ID列是主键中唯一的列吗?如果是这样,PK_INDEX仅在ID列中索引,还是在其中还有其他列?从所假设的主键中选择单个值时,我对188的基数感到惊讶。另外,您要更新的列有多少个索引? –
+1
另外,您的统计数据是否在表格及其索引上保持最新? –
+0
感谢您的参与 - 我已经包含了来自不同系统的解释计划。我已经在上面编辑过,包括正确的解释计划输出。 @Aleksey这也是为什么188行显示(它在开发系统中不是唯一值) –