现象：2017年12:21 日 核心系统某个模块跑批超时。
（为什么2018年还在写2017年的案例？因为本人驻场某银行，很多案例当时处理了写完报告，没法拷贝出来，你懂得！
只能等合适的"机会"，让人"帮忙"给拷贝出来，所以我的博客不更新则以一更新就是一大坨……现在我的案例刑满释放了！！）
通过查看会话发现是某个会话在执行sql b2j4crf66rpzn时间很长。等待事件为
| SQL*Net message to client |
|
查看该sqlb2j4crf66rpzn详情如下：
SQL语句的历史执行计划如下：
以上是我开发的优化工具抓取到的图片：可以看到plan2中存在会引起巨大性能问题的笛卡尔积
plan1的平均执行时间不到1秒，plan2平均执行时间则非常不稳定，从几秒到几千秒不等
针对这种突变快速解决只需要让SQL固定使用plan1：
绑定后效果如下图
可以看出该语句执行计划已经被绑定，SQL profile xxxx used for this statement
是不是很简单！同样需要注意 plan1绑定了SQL的执行计划就不会改变。如果相关表数据一直在增加。这个固定的执行计划在若干时间维度后就不一定是最优，甚至会很坑。所以有兴趣可以写一个脚本 排查数据库中潜在风险的SQL！思路:通过采集snapshot之间表数据增长 算出表的 “天增长” 计算某个若干天之后 这个作为某个连接方式驱动表或者被驱动表可能会引起性能问题！