问题描述：
解决过程：
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。