先看AWR报告，找到需要优化的SQL_ID
有时候AWR报告的SQL不完整，用ORA工具来查
拿到完整的SQL_TEXT，同时可以看到执行计划
明显可以看到，表KSYS_PLRENW的COST达到14391 执行时长近3分钟
备注一下：这个库里面有6个用户，同时有一些表也是同名的，所以上面这个SQL_ID的执行计划有6个，只是执行计划的哈希值不同，问过其他工程师，没法区分这6个执行计划是哪些用户执行的，那么只好一个个去优化，其实开发可以在SQL代码中带上注释就好区分了。
首先，看到是HASH JOIN，根据哈希连接和嵌套循环连接都是有驱动（左表）排序的，那么，优化的方向可以尝试左右表换位置，结果还是一样的（忘记截图了）
那么再继续往下观察
发现左表和右表都是走的是TABLE ACCESS FULL 全表扫描，这个时候其实就比较明显了，没有用到索引或者说用到的字段没有索引，同时左表的COST只有4，那么其实就可以忽略左表字段的索引建立，只对右表进行分析。
再回头看SQL语句
题外话，带有绑定变量怎么找出变量值
发现右表只有一个联合索引，而且还不是用到的那个字段，说明右表的pljypich这个字段没有索引，那么我们先优化这里，看看是否有提升
注意：先建立测试表测试再发布在生产上！
再执行一次，看看执行计划
可以看出，这个执行计划走了索引，COST从14391大幅缩减为6，执行时间由2分53秒减少为1秒
由于性能已经达到要求，至此，该优化有效，无需继续进行再优化（就算再优化也提高不了多少执行时间，同时也会增大索引存储开销）
