分页 + 模糊查询 有坑

前言

不知道你有没有使用过Mysql的like语句，进行模糊查询？

不知道你有没有将查询结果，进行分页处理？

模糊查询，加上分页处理，会有意想不到的坑，不信我们继续往下看。

我之前提供过一个品牌查询接口，给前端品牌选择控件使用的。

当时为了性能考虑，怕前端控件因为一次性加载太多的品牌，而导致页面卡死。

因此，对品牌查询接口做了分页处理。

刚开始品牌表的数据比较少，没有出现什么问题。

后来，产品加需求了，在品牌下拉选择控件中，让用户可以输入自定义品牌。

在用户添加品牌前，需要先查一下，如果该品牌存在，则使用已有品牌。如果不存在，则新增品牌。（这里是精确匹配）

这个需求很简单，很容易实现了。

后来，产品又加需求了，需要按名称模糊查询品牌。

该功能上线后，使用了很长一段时间，也没啥问题。

突然，在不经意的某一天，这个功能却出问题了。

到底怎么回事呢？

1.案发现场

某一天下午，运营找到测试反馈一个问题说：明明品牌苏三，已经存在了，但用户输入关键字：苏三时，系统没有让用户直接选择已有品牌，而是添加了一个叫：苏三的自定义的品牌。

我过去一看，还真的有问题。

不一会儿，就定位到原因了，初步判断是分页的问题。

搜索关键字：苏三，竟然出现了好几页的数据，把我惊呆了，品牌表怎么多了这么多数据了。

我查了数据库，其实数据量并不是特别多，但有些品牌名称比较特殊，有些品牌名称是多个品牌名称拼接而成的，比如：苏三,李四 或者 苏三,李四,王五，这是一个品牌。

其实是品牌名称建的不规范导致的问题，但已经没法让运营修改品牌了，只能通过技术手段解决目前的问题。

查询第一页的数据sql：

select * from brand w