truncate 比 delete 慢的原因。

之前发过一个帖子，这次想总结一下。
SQL> delete  from ac95;

已删除2行。

已用时间:  00: 00: 00.01

SQL> truncate table ac95;

表被截断。

已用时间:  00: 01: 32.88


我们看到truncate 花费了93秒的时间。慢的出奇。
查看建表语句：

------------------------------------------------------------------------------------------------------------------------------------
CREATE TABLE "NCSI"."AC95"
   (     略。。。   CONSTRAINT "PK_AC95" PRIMARY KEY ("AAC001", "AAE140", "AAE002", "BAE415", "BAC468")
  USING INDEX PCTFREE 10 INITRANS 2 MAXTRANS 255 NOLOGGING COMPUTE STATISTICS
  STORAGE(INITIAL 973078528 NEXT 1048576 MINEXTENTS 1 MAXEXTENTS 2147483645
  PCTINCREASE 0 FREELISTS 1 FREELIST GROUPS 1 BUFFER_POOL DEFAULT)
  TABLESPACE "USERS"  ENABLE
   ) PCTFREE 3 PCTUSED 40 INITRANS 1 MAXTRANS 255 NOCOMPRESS NOLOGGING
  STORAGE(INITIAL 16384 NEXT 1048576 MINEXTENTS 1 MAXEXTENTS 2147483645
  PCTINCREASE 0 FREELISTS 1 FREELIST GROUPS 1 BUFFER_POOL DEFAULT)
  TABLESPACE "USERS"

---------------------------------------------------------------------------------------------------------------------------------------
发现索引段的第一个区非常大，将近一个G.

 

而且这个表上，还存在7个类似这样的索引，索引的第一个区都比较大。

 

用10046跟踪，tkprof以后结果如下：

truncate table ac95


call     count       cpu    elapsed       disk      query    current        rows
------- ------  -------- ---------- ---------- ---------- ----------  ----------
Parse        1      0.00       0.00          0          0          0           0
Execute      1      0.15      82.94       2493         16       9069           0
Fetch        0      0.00       0.00          0          0          0           0
------- ------  -------- ---------- ---------- ---------- ----------  ----------
total        2      0.15      82.95       2493         16       9069           0

Misses in library cache during parse: 1
Optimizer mode: ALL_ROWS
Parsing user id: 55  

Elapsed times include waiting on following events:
  Event waited on                             Times   Max. Wait  Total Waited
  ----------------------------------------   Waited  ----------  ------------
  reliable message                                8        0.00          0.00
  enq: RO - fast object reuse                     8        0.53          1.38
  db file sequential read                      2493        0.44         15.95
  local write wait                             2131        0.39         65.41
  rdbms ipc reply                                16        0.00          0.00
  SQL*Net message to client                       1        0.00          0.00
  SQL*Net message from client                     1        0.00          0.00
********************************************************************************
时间主要花费在了local write wait，db file sequential read上面。

 

由于tkprof以后隐藏了很多信息，我们可以看看具体的local write wait，db file sequential read等待都发生在了那些数据上面。查看后发现这些等待都发生在索引段，表段的第一个区上，ORACLE需要把这些段第一个区的数据块读入buffer进行格式化。

 

 

而delete为什么比较块呢，因为他只需要读取高水位下使用过的块即可。

来自 “ ITPUB博客 ” ，链接：http://blog.itpub.net/22034023/viewspace-667768/，如需转载，请注明出处，否则将追究法律责任。

转载于:http://blog.itpub.net/22034023/viewspace-667768/