关于MySQL的模糊查询那些事？

MySQL查询中我们一般使用Like关键字来完成模糊查询，但是Like关键字查询的效率低是大家有目共睹的，那是因为在使用Like进行模糊查询的时候，会导致全表扫描，所以一般在数据量比较大的情况下不建议使用Like来进行数据的模糊查询。

那么既然Like会导致全表扫描，导致查询效率较低，那么有没有其他的方式可以代替Like来完成模糊查询呢？下面我们我们就来看看有哪些可以代替Like实现模糊查询的操作。

这里我们以日志操作信息表为例来进行演示，大概数据量在40W左右，忽略远程连接网络上带来的损耗。

Like语句

查询操作日志表里面包含“下载”的数据

SELECT * FROM option_log WHERE  log_title like "%下载%"

一共查询到8.6W条数据，消耗时间是64.979秒

SELECT id,log_title FROM ks_option_log WHERE  log_title like "%下载%"

一共查询到8.6W条数据，执行时间是2.847秒。

SELECT id,log_title FROM ks_option_log WHERE  log_title like "%pc%"

一共查询到的数据1.9W条数据，执行时间1.381秒

从这个查询结果可以看出，数据表的主键ID是被添加了索引的，有索引的参与整体的查询效率有大幅度的提升。另外可以看到，在查询返回值内容相同的情况下都是ID和日志标题，那么like命中的条数越少的情况下，查询时间耗时就越大

INSTR语句

同样的查询条件，我们使用instr函数来进行查询

SELECT id,log_title FROM ks_option_log WHERE INSTR(log_title,"下载")>0

查询结果8.6W，消耗时间2.666秒，相比较上面的结果查询时间确实有所提升。

LOCATE语句

INSTR(str, substr) 与LOCATE(substr, str) 类似，只是参数的位置变了。

SELECT id,log_title FROM ks_option_log WHERE LOCATE("下载",log_title)>0

查询结果8.6W，消耗时间2.747秒，相比较instr耗时有所提升。

LOCATE函数有点类似于JS中的 indexOf()，所以在查询效率上会一定的损耗比起INSTR来的话查询时间上有所变化。

POSITION语句

SELECT id,log_title FROM ks_option_log WHERE POSITION("下载" IN log_title)

查询结果8.6W条数据，执行时间2.635秒

LOCATE（）、POSITION（）、INSTR（）类似，执行效率基本一致，但INSTR()要前两者要稍微快一点，但是三者的整体执行效率表现上都要比Like语句要好。

FIND_IN_SET语句

该语句没有返回结果。

SELECT id,log_title FROM ks_option_log WHERE FIND_IN_SET("下载",log_title)

FIND_IN_SET(str,strlist)，语句官方的示意是如果在str是由N个子链字符串组成的字符串列表strlist中，并且返回的值是在1到N之间，那么就说明这个数据是存在的。这里需要特别说明，strlist是以逗号分隔的字符串，也就是如下所示。

SELECT FIND_IN_SET('b','a,b,c,d');

说明b这个字符，在a,b,c,d列表中。

LIKE是广泛的模糊匹配，字符串中没有分隔符，Find_IN_SET 是精确匹配，字段值以英文逗号分隔，Find_IN_SET查询的结果要小于like查询的结果，这也是因为LIKE是模糊匹配的关系。

总结

以上我们介绍了除Like之外的其余四种模糊查询的实现方式，分别是INSTR()函数，LOCATE()函数，POSITION()函数，FIND_IN_SET()函数等。其中INSTR()函数，LOCATE()函数，POSITION()函数的执行效率差不多，但是相比于LIKE效率有所提升，FIND_IN_SET()函数需要有特定的使用环境。