删除表的数据来提高SQL效率
尉迟边浩
今天上午查看em工具，在9点半的时候applications又升
到了60去，虽然很快释放，没有引起数据库慢，但是这
里还是重视一下。用上午8点到10的快照做成一个awr报告，
通过查看 SQL Statistice-SQL ordered by elapsed time，
找出排名第一的SQL,Sql如下：
-----------------------------------------------------------------
Select Message_Id,
Reciver_Employee_Id,
Msg_Type,
Msg_Title,
Msg_Content,
Operator_Time,
Linkurl,
Timeout,
Position_Id,
Awake_Time
From t_s_Message
Where (Show_Times > 0 And Awake_Time <= Sysdate)
Or (Show_Times > 0 And Awake_Time Is Null)
-----------------------------------------------------------------
查看这个SQL，发现执行计划很糟糕，其实就是一个全表扫描，
t_s_message这张表应该也清理一下了，但是整理数据库表空
间的时候看这个表小就暂时没有做处理，现在处理一下当时说
的t_s_message这张表留半年的
-----------------------------------------------------------------
删出表内容的时候要注意的一个地方
select a.owner 主键拥有者,
a.table_name 主键表,
b.column_name 主键列,
C.OWNER 外键拥有者,
c.table_name 外键表,
d.column_name 外键列
from user_constraints a,
user_cons_columns b,
user_constraints C,
user_cons_columns d
where a.constraint_name=b.constraint_name
and C.R_CONSTRAINT_NAME=a.constraint_name
and c.constraint_name=d.constraint_name
and a.constraint_type='P'
and a.table_name='T_S_MESSAGE' --需要查看主外键关系的表
order by a.table_name
-----------------------------------------------------------------
结果为零行，说明这个表里面的数据没有被其他表的外键所参考，
这样的话，这个表就可以删除，还是用移表的方式，直接删除肯
定还是会报外键约束删不掉的错误，但是如果用rename的方式移
除表的话，数据库就会报错了
----------------------------------------------------------------
Create Table t_s_Message_bak_2011 As Select * From t_s_message
保险期间还是分时间段删除，这个很重要，有次在测试机上面直接
删100W数据就出现了性能问题，整个数据库性能急剧下滑，当我要
停掉会话的时候发现还停不掉，我手工从系统层面将会话结束，不
过数据库仍然很慢，我知道据库还在做回滚，一次删除太多，回滚
的时间也会很长，而且在这期间仍然是影响性能的，所以正式库上
删除数据一定要小心再小心
-----------------------------------------------------------------
Delete From t_s_message a Where a.operator_time
Between to_date('2010-03-01 00:00:00','yyyy/MM/DD/ HH24:MI:SS')
and to_date('2011-01-01 00:00:00','yyyy/MM/DD/ HH24:MI:SS')
Delete From t_s_message a Where a.operator_time
Between to_date('2011-01-01 00:00:00','yyyy/MM/DD/ HH24:MI:SS')
and to_date('2011-06-01 00:00:00','yyyy/MM/DD/ HH24:MI:SS')
-----------------------------------------------------------------
删除完后，查看执行计划仍然没有改变，收缩一下表
SQL>alter table t_s_message shrink space;
SQL>alter index MESSAGE_RECIVER_POSTION_FK rebuild
SQL>alter index PK_T_S_MESSAGE rebuild
SQL>alter index CASE_MESSAGE_FK rebuild
SQL>alter index MESSAGE_SENDER_FK rebuild
SQL>alter index MESSAGE_RECIVER_FK rebuild
-----------------------------------------------------------------
这里直接用的rebuild，没有用online,速度比较快，他们的具体差异
收集一下统计信息
exec dbms_stats.gather_table_stats('GC','T_S_MESSAGE');
----------------------------------------------------------------
总结：
整个完成后，上面那条SQL运行就很快了，我渐渐意识
到有的SQL并不是说要如何如何优化，一个合理的业务
需求也是很重要的，在线交易系统里面的表是不是应该
控制一下大小，不能无限制的增大
到了60去，虽然很快释放，没有引起数据库慢，但是这
里还是重视一下。用上午8点到10的快照做成一个awr报告，
通过查看 SQL Statistice-SQL ordered by elapsed time，
找出排名第一的SQL,Sql如下：
-----------------------------------------------------------------
Select Message_Id,
Reciver_Employee_Id,
Msg_Type,
Msg_Title,
Msg_Content,
Operator_Time,
Linkurl,
Timeout,
Position_Id,
Awake_Time
From t_s_Message
Where (Show_Times > 0 And Awake_Time <= Sysdate)
Or (Show_Times > 0 And Awake_Time Is Null)
-----------------------------------------------------------------
查看这个SQL，发现执行计划很糟糕，其实就是一个全表扫描，
t_s_message这张表应该也清理一下了，但是整理数据库表空
间的时候看这个表小就暂时没有做处理，现在处理一下当时说
的t_s_message这张表留半年的
-----------------------------------------------------------------
删出表内容的时候要注意的一个地方
select a.owner 主键拥有者,
a.table_name 主键表,
b.column_name 主键列,
C.OWNER 外键拥有者,
c.table_name 外键表,
d.column_name 外键列
from user_constraints a,
user_cons_columns b,
user_constraints C,
user_cons_columns d
where a.constraint_name=b.constraint_name
and C.R_CONSTRAINT_NAME=a.constraint_name
and c.constraint_name=d.constraint_name
and a.constraint_type='P'
and a.table_name='T_S_MESSAGE' --需要查看主外键关系的表
order by a.table_name
-----------------------------------------------------------------
结果为零行，说明这个表里面的数据没有被其他表的外键所参考，
这样的话，这个表就可以删除，还是用移表的方式，直接删除肯
定还是会报外键约束删不掉的错误，但是如果用rename的方式移
除表的话，数据库就会报错了
----------------------------------------------------------------
Create Table t_s_Message_bak_2011 As Select * From t_s_message
保险期间还是分时间段删除，这个很重要，有次在测试机上面直接
删100W数据就出现了性能问题，整个数据库性能急剧下滑，当我要
停掉会话的时候发现还停不掉，我手工从系统层面将会话结束，不
过数据库仍然很慢，我知道据库还在做回滚，一次删除太多，回滚
的时间也会很长，而且在这期间仍然是影响性能的，所以正式库上
删除数据一定要小心再小心
-----------------------------------------------------------------
Delete From t_s_message a Where a.operator_time
Between to_date('2010-03-01 00:00:00','yyyy/MM/DD/ HH24:MI:SS')
and to_date('2011-01-01 00:00:00','yyyy/MM/DD/ HH24:MI:SS')
Delete From t_s_message a Where a.operator_time
Between to_date('2011-01-01 00:00:00','yyyy/MM/DD/ HH24:MI:SS')
and to_date('2011-06-01 00:00:00','yyyy/MM/DD/ HH24:MI:SS')
-----------------------------------------------------------------
删除完后，查看执行计划仍然没有改变，收缩一下表
SQL>alter table t_s_message shrink space;
SQL>alter index MESSAGE_RECIVER_POSTION_FK rebuild
SQL>alter index PK_T_S_MESSAGE rebuild
SQL>alter index CASE_MESSAGE_FK rebuild
SQL>alter index MESSAGE_SENDER_FK rebuild
SQL>alter index MESSAGE_RECIVER_FK rebuild
-----------------------------------------------------------------
这里直接用的rebuild，没有用online,速度比较快，他们的具体差异
大致说就是有一张临时表的过渡，让rebuild online的时候索引仍然
能正常使用，不过这种操作还是比较消耗系统资源，应当在系统较为
空闲的时候再做次操作关键差别还是在上的锁，以后还是用rebuild online
加了online是上2级锁，不加是上4级锁。
----------------------------------------------------------------收集一下统计信息
exec dbms_stats.gather_table_stats('GC','T_S_MESSAGE');
----------------------------------------------------------------
总结：
整个完成后，上面那条SQL运行就很快了，我渐渐意识
到有的SQL并不是说要如何如何优化，一个合理的业务
需求也是很重要的，在线交易系统里面的表是不是应该
控制一下大小，不能无限制的增大
类似资料：