百度360必应搜狗淘宝本站头条
当前位置:网站首页 > IT技术 > 正文

分页 + 模糊查询 有坑

wptr33 2024-11-19 12:26 34 浏览

大家好,我是苏三,又跟大家见面了。

前言

不知道你有没有使用过Mysqllike语句,进行模糊查询?

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

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

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

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

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

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

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

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

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

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

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

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

到底怎么回事呢?

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

把分页查询接口的数据,拆分成两部分:

  1. 精确查询
  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、苏三说技术。
  3. 从中间开始匹配,比如:1苏三、2苏三。
  4. 第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;

执行结果:

完美,终于出现我们想要的结果了。

除此之外,还可以使用:instrposition函数,它们的功能跟locate函数类似,在这里我就不一一介绍了,感兴趣的小伙伴可以找我私聊。

5. 总结

其实,模糊查询分页,如果分开用,一般是没问题的。

但如果它们要一起使用,一定要考虑排序问题。

如果只是按照简单的时间或者id排序,有些特殊的业务场景,没办法满足,很容易出现bug。

当然解决上面问题,还有其他办法,比如:pageSize调大一点,或者把全匹配放到第一页。

但更优的方案,是通过mysql的函数来解决问题。

我们可以通过mysql提供的:char_lengthlocateinstrposition函数等,来实现很多复杂的排序功能。


最后说一句(求关注,别白嫖我)

如果这篇文章对您有所帮助,或者有所启发的话,帮忙扫描下发二维码关注一下,您的支持是我坚持写作最大的动力。

求一键三连:点赞、转发、在看。

关注公众号:【苏三说技术】,在公众号中回复:面试、代码神器、开发手册、时间管理有超赞的粉丝福利,另外回复:加群,可以跟很多BAT大厂的前辈交流和学习。


相关推荐

MySQL进阶五之自动读写分离mysql-proxy

自动读写分离目前,大量现网用户的业务场景中存在读多写少、业务负载无法预测等情况,在有大量读请求的应用场景下,单个实例可能无法承受读取压力,甚至会对业务产生影响。为了实现读取能力的弹性扩展,分担数据库压...

Postgres vs MySQL_vs2022连接mysql数据库

...

3分钟短文 | Laravel SQL筛选两个日期之间的记录,怎么写?

引言今天说一个细分的需求,在模型中,或者使用laravel提供的EloquentORM功能,构造查询语句时,返回位于两个指定的日期之间的条目。应该怎么写?本文通过几个例子,为大家梳理一下。学习时...

一文由浅入深带你完全掌握MySQL的锁机制原理与应用

本文将跟大家聊聊InnoDB的锁。本文比较长,包括一条SQL是如何加锁的,一些加锁规则、如何分析和解决死锁问题等内容,建议耐心读完,肯定对大家有帮助的。为什么需要加锁呢?...

验证Mysql中联合索引的最左匹配原则

后端面试中一定是必问mysql的,在以往的面试中好几个面试官都反馈我Mysql基础不行,今天来着重复习一下自己的弱点知识。在Mysql调优中索引优化又是非常重要的方法,不管公司的大小只要后端项目中用到...

MySQL索引解析(联合索引/最左前缀/覆盖索引/索引下推)

目录1.索引基础...

你会看 MySQL 的执行计划(EXPLAIN)吗?

SQL执行太慢怎么办?我们通常会使用EXPLAIN命令来查看SQL的执行计划,然后根据执行计划找出问题所在并进行优化。用法简介...

MySQL 从入门到精通(四)之索引结构

索引概述索引(index),是帮助MySQL高效获取数据的数据结构(有序),在数据之外,数据库系统还维护者满足特定查询算法的数据结构,这些数据结构以某种方式引用(指向)数据,这样就可以在这些数据结构...

mysql总结——面试中最常问到的知识点

mysql作为开源数据库中的榜一大哥,一直是面试官们考察的重中之重。今天,我们来总结一下mysql的知识点,供大家复习参照,看完这些知识点,再加上一些边角细节,基本上能够应付大多mysql相关面试了(...

mysql总结——面试中最常问到的知识点(2)

首先我们回顾一下上篇内容,主要复习了索引,事务,锁,以及SQL优化的工具。本篇文章接着写后面的内容。性能优化索引优化,SQL中索引的相关优化主要有以下几个方面:最好是全匹配。如果是联合索引的话,遵循最...

MySQL基础全知全解!超详细无废话!轻松上手~

本期内容提醒:全篇2300+字,篇幅较长,可搭配饭菜一同“食”用,全篇无废话(除了这句),干货满满,可收藏供后期反复观看。注:MySQL中语法不区分大小写,本篇中...

深入剖析 MySQL 中的锁机制原理_mysql 锁详解

在互联网软件开发领域,MySQL作为一款广泛应用的关系型数据库管理系统,其锁机制在保障数据一致性和实现并发控制方面扮演着举足轻重的角色。对于互联网软件开发人员而言,深入理解MySQL的锁机制原理...

Java 与 MySQL 性能优化:MySQL分区表设计与性能优化全解析

引言在数据库管理领域,随着数据量的不断增长,如何高效地管理和操作数据成为了一个关键问题。MySQL分区表作为一种有效的数据管理技术,能够将大型表划分为多个更小、更易管理的分区,从而提升数据库的性能和可...

MySQL基础篇:DQL数据查询操作_mysql 查

一、基础查询DQL基础查询语法SELECT字段列表FROM表名列表WHERE条件列表GROUPBY分组字段列表HAVING分组后条件列表ORDERBY排序字段列表LIMIT...

MySql:索引的基本使用_mysql索引的使用和原理

一、索引基础概念1.什么是索引?索引是数据库表的特殊数据结构(通常是B+树),用于...