关于大数据分页查询的问题 谁借莪1个温暖的怀抱¢ 2022-05-13 15:34 153阅读 0赞 ### 文章目录 ### * 1、问题背景 * 2、问题描述 * 3、解决方案 * 4、总结 # 1、问题背景 # (1)待查询表中的数据超过4000万条; (2)已经对sql的进行过优化,对表结构等进行优化,并且已经对sql中的查询条件都添加了索引; (3)前端分页需要的数据格式如下: { "total": 0, "data": [] } # 2、问题描述 # * 在进行分页时,由于前端需要知道总的条数(total)。这里有两个普遍的解决办法:一是,在查询数据时,只执行一个sql,相当于查询所有,然后在程序中进行分页;二是执行两个sql,第一次查询分页的数据,第二次执行count()操作。 * 但是无论使用哪种方式,对于前端查询而言都会特别慢。 # 3、解决方案 # (1)方法一: * 不告诉前端总的数据量,不传total值。让用户一直点击“下一页”,当点击后返回数据为空,即表示已经到了最后一页。此时按钮变为不可用状态。这种做法的好处是,只执行一个分页的sql,效率比较高。 如下: { "data": [] } (2)方法2: * 但是为了不影响(或者降低)用户体验,增加一个参数,“isStill,表示是否还有下一页”。该参数为true表示有,false表示无。此时,后端需要执行两个分页的sql,每次查询都多执行后一次的分页。这种效率比count()的效率要高很多。 { isStill:true, "data": [] } (3)方法3: * 把查询总条数和查询源数据分为两个接口。每次查询时,只是分页的第一页需要同时查两个接口。并且当查询条件改变时,需要同时查两个接口。由前端判断查询条件是否改变了。注意,在查询总条数时,务必对sql进行简化,越简单越好。 (该方案,其实还有一种实现,就是由后端对总条数进行缓存(可以放内存/redis中),由后端判断查询条件是否改变。但是我建议使用前端判断的方法) ![在这里插入图片描述][20181213141627784.png] # 4、总结 # -------------------- * 方法一: 缺点是,用户不知道下一页是否还有数据,只有当点击了下一页按钮后才会知道; 优点是,效率高; * 方法二: 缺点是,多执行了一个分页的sql,效率较低; 优点是,用户体验好一些; * 方法三: **个人推荐!** -------------------- 在执行count()查总条数的sql时,使用最简单的sql进行(比如,去掉排序,去掉多余的表联合,使用count(1)代替count(\*)等); 但是,如果连第一次count()都慢的查不出来时,那就没办法了,要不做分表分库,要不使用方法二。 -------------------- 慢查询一是,会严重降低数据库性能,如果有多个应用程序都需要操作数据库的话,会导致所有应用都无法使用(我在生产环境就遇到了这个问题,非常严重的问题,生产环境中整个系统无法使用,原因就是mysql卡死);二是,数据查询非常慢,用户等待时间过长,用户体验非常差,而且还可能造成前端请求超时。 [20181213141627784.png]: /images/20220504/c03f1b6eeeba45388b1715333c5c90da.png
还没有评论,来说两句吧...