文章讨论的是本来应该建立索引而因为疏忽，或者考虑不周全而没有建立的情况

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查询结果只做参考。具体问题还要具体分析。
当然这个是一个亡羊补牢的方法，我们在开发设计时，应该提起考虑好，那些列会用到索引，提起建立好，而不是出现性能问题在做。

您可能感兴趣的文章: