Mybatis-Plus分页插件查询慢解决方案

文章讲述了前端界面查询速度慢的问题,经分析发现是由于Mybatis-Plus的PaginationInterceptor中的optimizeCountSql优化导致的。通过关闭优化并自定义count查询或减少复杂SQL中的转换函数,解决了查询速度问题。作者还提出了后续的优化方向,如字典优化和数据库冗余字段查询。
摘要由CSDN通过智能技术生成

原文链接:https://blog.csdn.net/hoho_12/article/details/129207364

问题
需求反馈前端界面查询速度很慢。

分析
f12查看接口响应时间达到了5.47s。

查看后端代码逻辑,就是传了些参数,分页查询了一个列表的数据。分页插件使用的是mybatis-plus的分页插件,PaginationInterceptor。

把后端调用的sql单独拿出来在navicat中进行执行,才0.54s左右,其实很快了,数据量也不大。分页查询即使加上查总数的count语句,单独拿出来在navicat中执行,也很快。

综上,总体来说这次响应速度慢和sql查询的关系不是很大,查看后台日志时发现,在打印出sql语句之后,会卡顿一会儿,随后才会输出count语句。查阅mybatis-plus插件的官网发现,其中有个参数: optimizeCountSql , 默认为true。在编写count语句的时候,会对sql语句进行优化。

以此推断应该是这个引起的,因为业务中sql语句还比较复杂,这里要解析进行优化的话,可能需要花费一点儿时间。尤其其中有一些难以解析的表达式,更是耗费时间。

解决方案
将上述属性设置为false,测试之后解决问题,接口的速度达到500多毫秒。

Page page = new Page();
page.setCurrent(MapUtils.getIntValue(paramMap, “pageNum”));
page.setSize(MapUtils.getIntValue(paramMap, “pageSize”));
// 关闭count sql的优化,解决前端查询慢的效率问题。
page.setOptimizeCountSql(false);
还有种方案,就是这里自定义一个count查询的sql,不用其优化的sql。即利用下图中的countId属性来解决。或者单独把总数查询出来后,再来设置其总数。

后续思考
此例中,sql语句写的比较复杂,查询的字段中用了很多转换函数,后续也需要继续优化。是否考虑关于字典的优化放在前端去显示。或者数据库冗余字段,直接查询,不用转换?
————————————————

                        版权声明:本文为博主原创文章,遵循 CC 4.0 BY-SA 版权协议,转载请附上原文出处链接和本声明。
  • 1
    点赞
  • 0
    收藏
    觉得还不错? 一键收藏
  • 1
    评论

“相关推荐”对你有帮助么?

  • 非常没帮助
  • 没帮助
  • 一般
  • 有帮助
  • 非常有帮助
提交
评论 1
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值