前言
不知道你有没有使用过Mysql的like语句进行模糊查询？
不知道你有没有将查询结果进行分页处理？
模糊查询，加上分页处理，会有意想不到的坑，不信我们继续往下看。
我之前提供过一个品牌查询接口，给前端品牌选择控件使用的。
当时为了性能考虑，怕前端控件因为一次性加载太多的品牌，而导致页面卡死。
因此，对品牌查询接口做了分页处理。
刚开始品牌表的数据比较少，没有出现什么问题。
后来，产品加需求了，在品牌下拉选择控件中，让用户可以输入自定义品牌。
在用户添加品牌前，需要先查一下，如果该品牌存在，则使用已有品牌。如果不存在，则新增品牌。（这里是精确匹配）
这个需求很简单，很容易实现了。
后来，产品又加需求了，需要按名称模糊查询品牌。
该功能上线后，使用了很长一段时间，也没啥问题。
突然，在不经意的某一天，这个功能却出问题了。
到底怎么回事呢？
1.案例背景
某一天下午，运营找到测试反馈一个问题说：明明品牌“苏三”已经存在了，但用户输入关键字苏三时，系统没有让用户直接选择已有品牌，而是添加了一个叫“苏三”的自定义品牌。
我过去一看，还真的有问题。
不一会儿，就定位到原因了，初步判断是分页的问题。
搜索关键字苏三，竟然出现了好几页的数据，把我惊呆了，品牌表怎么多了这么多数据了。
我查了数据库，其实数据量并不是特别多，但有些品牌名称比较特殊，有些品牌名称是多个品牌名称拼接而成的，比如：“苏三,李四”或者“苏三,李四,王五”，这是一个品牌。
其实是品牌名称建得不规范导致的问题，但已经没法让运营修改品牌了，只能通过技术手段解决目前的问题。
查询第一页的数据 sql：
select * from brand where name like '%苏三%'
order by edit_date desc limit 5;
执行结果：
我们可以看到，图中并没有等于苏三这两个字的数据。
注意：为了好演示，这里给的每页大小是 5，真实的场景并非如此。
查询第二页的数据 sql：
select * from brand where name like '%苏三%'
order by edit_date desc limit 5,5;
执行结果：
从图中看到，在第二行，出现了正好等于苏三这两个字的数据。
用户搜索关键字苏三时，前端页面调用品牌查询接口，pageNo默认是1。由于能够匹配关键字的数据太多了，第一页返回不完，需要多页才能全部返回。
前端获取到第一页的数据后，跟关键字苏三做比较，发现没有等于“苏三”的品牌。
这样就会在下拉控件中，自动添加一个品牌“苏三”，同时在右边增加自定义标签。
这样就出问题了，明明“苏三”这个品牌是有的，但用户还能自定义一个“苏三”，而不是直接选择。
2.思考 123
苏三这个关键字，通过模糊查询可以查询出来，但由于品牌接口做了分页，全匹配的品牌“苏三”，出现在第二页了，才导致问题的产生。
如果要解决这个问题，让它出现在第一页不就 OK 了？
这时候，就有下面几种解决方案。
2.1 方案 1
分页查询品牌接口，pageSize是 5。
我们为什么不把 pageSize 调大一点？比如改成：200、500 等。
这样通过苏三关键字，进行模糊查询的时候，结果基本都在第一页。
这样就能非常快速地解决问题。
但有个缺点就是：如果这次调大了 pageSize，但后面查询关键字的品牌又出现在第二页怎么办？
不可能一直改 pageSize 吧？
2.2 方案 2
把分页查询接口的数据，拆分成两部分：
-
精确查询 -
模糊查询
在代码中做处理的时候，先根据关键字精确查询，即 sql 中使用name='苏三'这种方式查询一次数据。
如果没查出数据，则再直接用like '%苏三'进行模糊查询。
如果查出了一条数据，则把它放在返回结果集合中的第一位置。接下来，使用like '%苏三'进行模糊查询的时候，再加上条件 name '苏三'。将查出的结果，从第二个位置往后放。
这样可以拼接出你想要的集合。
但有个缺点，就是代码耦合性太大了。
2.3 方案 3
之前，品牌“苏三”在第二页，最根本的原因是使用了edit_time字段进行逆序的。
也就是说，修改时间越大的越排在前面，而品牌“苏三”的修改时间很小，所以排在第二页了。
如果想让品牌“苏三”排在第一页，修改一下排序规则，不就搞定了？
可以改成按 id 或者 name 字段排序。
用 id 字段排序，不太合适，虽说用了雪花算法，但跟修改时间类似，先插入的数据，会越小。
select * from brand where name like '%苏三%'
order by id desc limit 5;
用它排序的结果，跟使用修改时间排序差不了太多。
看来，只能使用 name 字段排序了。
3.如何排序？
我们在 sql 中直接对 name 字段进行升序或者降序吗？
显然不是。
使用 name 字段降序：
select * from brand where name like '%苏三%'
order by name desc limit 5;
执行结果：
图中并没有看到我们想要的数据。
其实，使用 name 字段升序，也可能在第一页查不出我们所想要的数据。
到底该如何处理呢？
假如，我们有这样一种排序：
-
全匹配显示在最前面，比如：苏三。 -
数据左半部分匹配，右边按字母排序，比如：苏三1、苏三2、苏三说技术。 -
从中间开始匹配，比如：1苏三、2苏三。 -
第 2 步和第 3 步，还要根据字符长度排序，字符短的排在前面，比如：1苏三、1苏三1、苏三说技术。
如果我们能实现上面的这种排序方式，这个问题就能完美解决了。
说起来容易，做起来难。
难道要先全匹配：name='苏三'，再右匹配：name like '苏三%'，再左匹配：name like '%苏三'，把查询三次的结果组装起来？
显然这种做法有点 low。
要实现上面我们设想的排序方式，在es中更好处理，但在mysql中要怎么处理呢？
4.解决方案
其实，我们可以换一种思路，根据字符的长度排序。
mysql 给我们提供了很多非常有用的函数，比如：char_length。
通过该函数就能获取字符长度。
sql 调整如下：
select * from brand where name like '%苏三%'
order by char_length(name) asc limit 5;
name 字段使用关键字模糊查询之后，再使用char_length函数，获取 name 字段的字符长度，然后按长度升序。
仅这一个骚操作，就搞定需求了：
我们所期待的“苏三”，终于排在第一个了。同时由于该 sql 做了分页，即使 name 字段在查询时丢失了索引，执行效率也不会太低。
业务上的需求搞定了。
但追求完美的我们，好奇想看看第二页是什么情况：
select * from brand where name like '%苏三%'
order by char_length(name) asc limit 5,5;
执行结果：
并没有按照我们设想的剧本进行下去，我们之前假设的 3 条排序中，第 2 条和第 3 条都没有满足。
这时该怎么办？
答：可以使用 mysql 中的locate函数，通过它可以匹配出关键字在字符串中的位置。
使用locate函数改造之后 sql 如下：
select * from brand where name like '%苏三%'
order by char_length(name) asc, locate('苏三',name) asc limit 5,5;
执行结果：
完美，终于出现我们想要的结果了。
除此之外，还可以使用：instr和position函数，它们的功能跟locate函数类似，在这里就不一一介绍了。
5. 总结
其实，模糊查询和分页，如果分开用，一般是没问题的。
但如果它们要一起使用，一定要考虑排序问题。
如果只是按照简单的时间或者 id 排序，有些特殊的业务场景，没办法满足，很容易出现 bug。
当然解决上面问题，还有其他办法，比如：pageSize 调大一点，或者把全匹配放到第一页。
但更优的方案是通过 mysql 的函数来解决问题。
我们可以通过 mysql 提供的：char_length、locate、instr和position等函数，来实现很多复杂的排序功能。
