常规like的使用限制：

1. like %keyword ：索引失效，使用全表扫描。但可以通过翻转函数+like前模糊查询+建立翻转函数索引=走翻转函数索引，不走全表扫描。

2. like keyword% ：索引有效。

3. like %keyword% ：索引失效，也无法使用反向索引。


MySql使用内置函数实现模糊查询：

1. 使用locate()方法
1.1.普通用法：

SELECT `column` from `table` where locate('keyword', `condition`)>0

    类似于 java 的 indexOf();不过 locate() 只要找到返回的结果都大于0(即使是查询的内容就是最开始部分)，没有查找到才返回0；
1.2. 指定其实位置：

SELECT LOCATE('bar', 'foobarbar',5);  --> 7

    从foobarbar的第五个位置开始查找 


2.使用instr()函数 (据说是locate()的别名函数)

SELECT `column` from `table` where instr(`condition`, ‘keyword’ )>0

    唯一不同的是 查询内容的位置不同，见SQL语句中过的keyword


3.使用position()方法

   据说也是locate()方法的别名函数，功能一样 

SELECT `column` from `table` where position(‘keyword’ IN `condition`)

   不过它不再是通过返回值来判断，而是使用关键字in


4.使用find_in_set()函数
   如： find_in_set(str,strlist)，strlist必须要是以逗号分隔的字符串
   如果字符串str是在的strlist组成的N子串的字符串列表，返回值的范围为1到N

SQL> SELECT FIND_IN_SET('b','a,b,c,d');
+---------------------------------------------------------+
| SELECT FIND_IN_SET('b','a,b,c,d')                       |
+---------------------------------------------------------+
| 2                                                       |
+---------------------------------------------------------+
1 row in set (0.00 sec)

总结： locate、position 和 instr 的差別只是参数的位置不同，同时locate 多一个起始位置的参数外，两者是一样的。
find_in_set()是个比较特殊的存在，但它们都是返回要查找的子字符串 在 指定字符串中的位置。速度上前3个比用 like 稍快了一点(不过这四个函数都不能使用索引，这是个遗憾)。


查询%xx的记录优化

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')

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