一则SQL优化，解决oracle数据库性能问题----解决前模糊查询性能问题

1。根据观察，发现以下sql

 

select count(c.c_ply_no) as COUNT

  from Policy_Data_All c, Item_Data_All i

 where c.c_ply_no = i.c_ply_no

   and i.C_LCN_NO like '%245'

在执行的时候，执行计划显示，消耗值，io值，cpu值均非常大，原因是 like 后面前模糊查询导致索引失效，进行全表扫描

 

 

解决方法：这种只有前模糊的sql可以改造如下写法

select count(c.c_ply_no) as COUNT

  from Policy_Data_All c, Item_Data_All i

 where c.c_ply_no = i.c_ply_no

   and reverse(i.C_LCN_NO) like reverse('%245')

 

 Item_Data_All 表的C_LCN_NO字段进行前模糊匹配的情况都可以这样处理。例如这段：

select *

  from (select c.c_ply_no as c67_0_,

               c.c_insrnt_cnm as c68_1432_0_,

               i.C_LCN_NO as C83_1432_0_,

               TO_CHAR(c.T_INSRNC_BGN_TM, 'yyyy-mm-dd') as T84_1432_0_,

               c.c_edr_type as c85_1432_0_,

               c.C_prod_no as C86_1432_0_,

               c.C_INTER_CDE as CInterCde1432_0_

          from Policy_Data_All c, Item_Data_All i

         where c.c_ply_no = i.c_ply_no

           and reverse(i.C_LCN_NO)  like  reverse('%434')

         order by c.c_ply_no DESC)

使用 翻转函数+like前模糊查询+建立翻转函数索引=走翻转函数索引，不走全扫描。有效降低消耗值，io值，cpu值这三个指标，尤其是io值的降低。

 

对于like的查询条件，后模糊，可以利用索引，但是前模糊就不可能走索引了，用以上方法可以实现对like 前模糊的优化。但是对于like的前后模糊查询我还没做过相关研究和优化工作。

来自 “ ITPUB博客 ” ，链接：http://blog.itpub.net/22782896/viewspace-676065/，如需转载，请注明出处，否则将追究法律责任。

转载于:http://blog.itpub.net/22782896/viewspace-676065/