Oracle通过主键id删除记录很慢

kgbjqerrgt

问题描述：

Oracle通过主键id删除2000条记录很慢，需要花费十二分钟。

解决过程：

1.首先查看SQL的执行计划，执行计划正常，cost只有4，用到了主键索引。

2.查看等待事件，

select * from v$session_wait where sid = 507

显示的event是db file sequential read,也没有异常。

3.查看统计信息是否正常

select * from user_tables where table_name = '';

经检测，统计信息也是正常的。

4.查看系统IO，也是正常的。

5.找不到原因，开启SQL跟踪

alter session set events='10046 trace name context forever,level 12';

delete from t_table1 where id >= xxx

alter session set events='10046 trace name context off';

SQL跟踪得到一个trace文件

tkprof orcl_ora_3708.trc myoutput.txt

cat myoutput.txt，这次发现异常，文件里面除了有delete语句，还有两个select语句:

select /*+ all_rows */ count(1)
from
"xxx"."T_TABLE2" where "FRESHMANID" = :1

call    count      cpu    elapsed      disk      query    current        rows
------- ------  -------- ---------- ---------- ---------- ----------  ----------
Parse        1      0.00      0.00          0          0          0          0
Execute  2000      0.23      0.22          0          0          0          0
Fetch    2000    720.58    740.36        842  61038000          0        2000
------- ------  -------- ---------- ---------- ---------- ----------  ----------
total    4001    720.82    740.59        842  61038000          0        2000




select /*+ all_rows */ count(1)
from
"xxx"."T_TABLE3" where "FRESHMANID" = :1


call    count      cpu    elapsed      disk      query    current        rows
------- ------  -------- ---------- ---------- ---------- ----------  ----------
Parse        1      0.00      0.00          0          0          0          0
Execute  2000      0.27      0.27          0          0          0          0
Fetch    2000      1.84      1.93          0    136000          0        2000
------- ------  -------- ---------- ---------- ---------- ----------  ----------
total    4001      2.11      2.20          0    136000          0        2000

这两张表各查询了2000次，可以判断出来，就是因为这个原因导致delete非常慢，询问现场相关人员，t_table2、t_table3跟t_table1有什么关系，现场人员说t_table2和t_table3个有一个外键

依赖t_table1的主键ID，经过查询,t_table2和t_table3的外键上都没有创建索引，于是创建索引，再执行delete语句，这次执行速度很快，经过SQL跟踪，也没有发现去查询t_table2和t_table3。