某天一早DBA通过监控发现数据库中有一句执行异常的新语句，推断是前天新上线的sql，语句内容如下：
select * from T_xxx_ORDER O where ORDER_ID = 151028099726338
虽然是很简单的语句,但这里有两个比较严重的问题 ：
1.ORDER_ID是varchar2类型，而谓词中给了number类型的条件，这样就造成了数据库中发生隐式转换无法走ORDER_ID字段的索引，执行计划只能选择走全表扫描了，而该表有3.73个G，这单句sql的执行时间要近3分钟 ；
2. 没有绑定变量，造成硬解析高，影响数据库性能 语句修改方案如下： select * from T_xxx_ORDER where ORDER_ID = :1 变量传入varchar类型 由于该语句执行比较频繁，给数据库造成明显的IO压力；
sql是服务于业务的，查询变得很慢，那么已连接的查询会话就会保持不断开，这样容易导致数据库连接数满或者应用侧有积压（应用指定了数据库连接数，用满了后只能等待在队列里）或者应用超时，最终会造成业务堵塞。
发现问题后DBA通过查询sql的发起机器很快定位了程序模块，当即联系了开发人员，开发人员表示只能今晚紧急修改上线。 然而，由于某省还有该业务的优惠活动，1个小时后业务部门发现对应业务无法正常进行，并接到了一定量的客户投诉。为了避免影响扩张，只能在应用侧紧急关闭了该业务通道，并立即将问题程序修改上线。
造成这个这个事件的原因是多面的，归纳如下：
开发人员的sql能力有限，没有变量绑定、避免隐式转换常识；
开发人员没有严格按照开发流程开发，导致该sql上线前没有经过DBA审核而直接上线。
作为DBA我们对问题sql波及业务的敏感性还有待提高，问题一开始就要从sql联想到相关业务影响并及做到时预警。
附原程序代码：
改为：
