统计信息问题造成的执行计划糟糕的一个例子（找原因）
昨天的报表数据库中有一条SQL，执行计划很差 ，Full table scan ，索引以及全部统计信息完整。SELECT × FROM wPay201004 WHERE org_code='01013340C' AND op_code not in ('1330');用户很着急，试着采取了几个方法 ：
1.删除统计信息，重新收集
2.对索引进行重建。
结果还是不通过索引来进行查询。强行在SQL语句中加上hint提示（/*+ index(wpay201004 wpay201004_idx2) */），执行计划可以了，可这就要改程序，已经来不及，只能想别的方法。这是一张月份表，同样对比前一个月的查询，3月的执行计划通过走了索引而四月却是全表扫描，效率差了一大截。仔细查看，表、索引结构相同，唯一的差别就是统计信息数值不一样。我跟用户说换个思路，把3月表的统计信息复制到4月，通过这种方法改变执行计划，得到用户的肯定我开始进行操作。建stata表
execute DBMS_STATS.CREATE_STAT_TABLE(ownname=>'owner',stattab=>'stat_tab',tblspace=>'ts_name');
导出表wpay201003分析数据:
execute DBMS_STATS.export_table_stats(ownname=>'owner',tabname=>'wpay201003',stattab=>'stat_tab');
删除表wpay201004的分析数据:
execute dbms_stats.delete_table_stats(ownname=>'owner',tabname=>'wpay201004');
修改统计信息
对stat_tab统计信息做休息，让数据复合wpay201004使用。
导入分析数据
execute DBMS_STATS.IMPORT_TABLE_STATS(ownname=>'owner',tabname=>'wpay201004',stattab=>'stat_tab');完成，测试结果完全按照预想，执行计划走了索引。执行时间从50多秒缩短到4秒左右。
什么原因呢？我怀疑是作者在收集统计信息的时候，使用了块采样，造成了错误的统计信息，应该进行全扫描的方式进行统计信息的收集（细细的研究dbms_stats包里面的一些具体的细节）。 这样的思路初学者确实很难想到 学习学习 "对stat_tab统计信息做休息，让数据复合wpay201004使用。" 请问大师，这句话是什么意思？
另外这个导出导入的方式，和 DBMS_STATS.copy_table_stats 有什么不同？
页:
[1]