在使用msyql进行模糊查询的时候，很自然的会用到like语句，通常情况下，在数据量小的时候，不容易看出查询的效率，但在数据量达到百万级，千万级的时候，查询的效率就很容易显现出来。这个时候查询的效率就显得很重要！

一般情况下like模糊查询的写法为（field已建立索引）：

SELECT column FROM table WHERE field like ‘%keyword%’;

上面的语句用explain解释来看，SQL语句并未用到索引，而且是全表搜索，如果在数据量超大的时候，可想而知最后的效率会是这样

对比下面的写法：

SELECT column FROM table WHERE field like ‘keyword%’;

这样的写法用explain解释看到，SQL语句使用了索引，搜索的效率大大的提高了！

但是有的时候，我们在做模糊查询的时候，并非要想查询的关键词都在开头，所以如果不是特别的要求，”keywork%”并不合适所有的模糊查询

这个时候，我们可以考虑用其他的方法

事实上，可以使用 locate(position) 和 instr 这两个函数来代替

一、LOCATE语句

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

二、或是 locate 的別名 position
POSITION语句

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

三、INSTR语句

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

locate、position 和 instr 的差別只是参数的位置不同，同时locate 多一个起始位置的参数外，两者是一样的。
mysql> SELECT LOCATE(‘bar’, ‘foobarbar’,5);

-> 7

速度上这三个比用 like 稍快了一点。

~~~~~~~~~~~~~~~~~~~~~~~华丽的分割线~~~~~~~~~~~~~~~~~~~~~~~~~~~~

四、还要给大家介绍一个新成员，那就是find_in_set

find_in_set(str1,str2) 函数：返回str2中str1所在的位置索引，其中str2必须以","分割开。

表：

mysql> select * from region;
+----+-------------+
| id | name        |
+----+-------------+
| 1  | name1,nam2  |
| 2  | name1       |
| 3  | name3       |
| 4  | name2,name4 |
| 5  | name3,name5 |
+----+-------------+
5 rows in set (0.00 sec)

FIND_IN_SET语句

mysql> select * from test where find_in_set('name1',name);
+----+------------+
| id | name       |
+----+------------+
| 1  | name1,nam2 |
| 2  | name1      |
+----+------------+
2 rows in set (0.02 sec)

五、当然，还有mysql的全文索引

全文索引：http://dev.mysql.com/doc/refman/5.6/en/fulltext-search.html

 

文章来源：

https://blog.csdn.net/liuxinyang666/article/details/78957003

https://blog.csdn.net/wpfphp/article/details/52584232

下面讲的不是模糊匹配，而是数据量大的情况下如何优化查询。
user 表录入 100万的数据，同时建立 user_category 表，每个user有 3 个分类，那么category表里有300万条记录。

CREATE TABLE `user_category` (  
  `id` int(11) NOT NULL AUTO_INCREMENT,  
  `user_id` int(11) DEFAULT NULL,  
  `category_id` int(11) DEFAULT NULL,  
  PRIMARY KEY (`id`),  
  KEY `category_id` (`category_id`),  
  KEY `user_id` (`tax_id`)  
) ENGINE=InnoDB AUTO_INCREMENT=1 DEFAULT   

现在比较一下在百万级的数据量上使用 join 链接外键查询和find_in_set查询的性能

1. 使用 find_in_set 查询，平均时间在2.2秒左右

SELECT SQL_NO_CACHE COUNT(*) FROM `user` WHERE FIND_IN_SET(65,category)  

2. 使用left join ， 使用了右表中的索引，平均时间在0.2秒左右

SELECT SQL_NO_CACHE COUNT(DISTINCT(`user`.id)) FROM `user`   
LEFT JOIN `user_category` ON `user`.`id`= `user_category`.`user_id`  
WHERE `user_category`.`category_id`=75  

所以在大数据量的情况下还是不适合用find_in_set, 不过有些表的数据可能永远就那么点数据，这个时候为了减少表数量，倒是可以用这样的方法做。
文章来源：https://jonny131.iteye.com/blog/771753