还是报表上的SQL，不多说了，放代码。
优化前
耗时：19min
返回：79215
SQL代码：
SQL执行计划：
--后面远程查询的sql就不放上来了，太长了。。
根据执行计划关键字VIEW：
可以得知SQL语句中from后面的关联查询，并没有执行视图合并。
Oracle对包含视图的目标SQL做简单视图合并是有前提条件的，该SQL所包含视图的视图定义SQL语句中一定不能出现如下内容（包括但不限于）：
1）集合运算符(UNION,UNION ALL INTERSECT, MINUS)
2）CONNECT BY子句
3）ROWNUM
4）...
所以我们可以把每个from后面的（select）作为一个单元体，然后分别执行。
得知以下信息：
T3 | 返回1064行 |
td | 返回5w |
s | 返回38w |
t1（视图MM_POLICYLIST_TI_V） | 需要执行很久。由此可以确定性能瓶颈在此视图上 |
T(表MM_POLICY_TI) | 返回77W，加条件t.certitype = '2' 返回5w数据，可以在此表上的certitype建立索引。尽管certitype字段选择性几乎为0 create index IDX_MM_POLICY_TI_02 on MM_POLICY_TI (CERTITYPE)； |
MM_POLICYLIST_TI_V视图定义
MM_POLICYLIST_TI_V视图执行计划
注意观察id=6关键字为filter，且 id=10被驱动表走了 索引跳跃扫描。
优化方法：
在谓词信息一栏中查找有绑定变量值的字段，并建立索引
优化完成后，再来运行整体SQL，4min15s能出结果。
对优化结果还不满意，继续优化。
观察id=7，表的连接方式为nested loops,
id=8驱动表为之前优化的视图(需要返回>60w以上数据)，
id=13被驱动表为T表（加条件返回5w数据）.
此时可以想到，这里应该让sql走hash连接的方式进行处理，所以我们可以添加以下hint
/*+use_hash(t,t1) leading(t) */
优化后
执行计划：
执行时间：1min 21s
优化到此
