是什么操作把SQL性能提高了6倍多？

今天这个案例不看SQL，看优化前后的执行计划就可以了：

优化前，最终返回3096条记录，耗时4146秒（执行时间看第一行中间的timeline）：

优化后，最终返回185K记录，耗时653秒：

优化后SQL执行计划没有变化，耗时最多步骤返回的记录数多了，最终返回的记录数也是优化前的6倍多，执行时间却变成了优化前的1/6，到底做了什么优化操作？

欲知后事如何，且听下回分解，给大家留一个思考的时间！

有思路的朋友可以留言讨论。

公众号的原创声明必须够300字，那就补充点其他内容，关于cardinality feedback：

搞优化的人总是喜欢找毛病：昨天看了一篇关于cardinality feedback bug导致SQL出现性能问题的文章，在分析SQL执行计划时使用的是plsql developer工具。其实plsql developer工具作为plsql 开发调试工具来说是非常不错的，但是作为查看执行计划的工具，显示的信息就差很多，补充信息无法显示，用它查看执行计划的唯一的好处就是各执行步骤层次感比较清晰，但是这一点比sql monitor又差很多。

如果是在sqlplus 下，简单的使用dbms_xplan.display_cursor命令，就能比较明确的在note部分看到“cardinality feedback used for this statement”这句话，可以马上证实是cardinality feedback导致的问题。因为，有经验的DBA遇到SQL第二次执行比第一次慢的情况，第一时间就能想到是cardinality feedback 的问题。dbms_xplan.display_cursor如果使用了advanced选项，显示的内容就更丰富了。

老虎刘有一个很简单的cardinality feedback的test case，可以用来测试sql profile工具（使用coe_load_sql_profile.sql脚本）：

create table t1 as select * from dba_objects;

create table t4 as select * from t1 sample(10);

create index IDX_OBJID_T4 on t4(object_id);

exec dbms_stats.gather_table_stats(user,'T1');

exec dbms_stats.gather_table_stats(user,'T4');

执行下面sql，第一次快，第二次及以后慢：

select count(*) from t1 left join t4

on t1.object_id=t4.object_id and t1.object_id>0

and (t1.created = t4.created or t1.created=t4.LAST_DDL_TIME);

非常简单的test case，自己动手测试一下吧！这个case在12c没有cardinality feedback的问题。