文章讨论的是本来应该建立索引而因为疏忽,或者考虑不周全而没有建立的情况
select distinct sp.OBJECT_NAME,round(ds.bytes/1024/1024,2) MB,num_rows,last_analyzed
from v$sql_plan sp ,v$sqlarea sq,dba_segments ds,dba_tables dt
where sq.ADDRESS=sp.ADDRESS
and ds.segment_name=sp.object_name
and dt.table_name=ds.segment_name
and sp.options=’FULL’
and dt.owner=’用户名’
and round(ds.bytes/1024/1024,2)>1
order by round(ds.bytes/1024/1024,2);
以上sql是:
通过定位到用户,找到在v$sql_plan里发生全表扫描的表。
并通过其他视图表(dba_tables,dba_segments)的关联,列出它的一些详细信息:大小,行数,分析时间。
我们可以再加一列,sq.sql_text把sql打印出来。
其中添加了一个条件是表的大小大于1M的表,一般情况下1M的表应该是1万行左右。(如果1M的表行数很少的话,那可能需要回收高水位线)
经测试,公司生产库中操作表(operate_detail)1万行数据在25M左右,
account_operate_detail表1万行数据4.5M左右。
小表的话我们不考虑,因为走全表扫描可能更快。
这个sql查询结果只做参考。具体问题还要具体分析。
当然这个是一个亡羊补牢的方法,我们在开发设计时,应该提起考虑好,那些列会用到索引,,提起建立好,而不是出现性能问题在做。