就因为多一个%，害的整个服务器差点挂掉
oralce10g数据库一张表，由于一个表数据量比较大，大概1.5亿数据，由于数据库结构不是很合理，导致该表有40G大小，但是客户需要导出一个明细，所以建立了一个联合索引，根据
? p_index区域，销售时间sell_date，在进行plan测试中，发现该语句还是比较给力的，效率也都不错，
?
但是在正式系统中，总是出现写redo出现1000ms的等待，而且在wait sql也都是被这个语句给占了，郁闷致死，查了N天之后，发现罪魁祸首，原来，改明细查询存在一个导出到excel功能，结果不知道那位老大写的时候把p_index like ':1%'给修改为p_index like '%:1%',导致无法搜联合索引，导致效率低下，也就多了一个%，害死人啊，修改完毕之后，系统立马跑的刷刷的。
?
原先标准的查询语句应该是这样的
?
where p_index like '340101%' and sell_date>=:1 and sell_date<:2
?
但是了，早导出到excel时候，被修改成了
?
where p_index like '%340101%' and sell_date>=:1 and sell_date<:2
?
所以啊，一个小小的失误，会害死一个庞大的系统的。。也就是说“细节决定成败”。
?
?
