bug级别的分页查询缓慢,并非是sql语句的锅

首先上图:

 

问题:

业务复杂度并不高的分页列表接口,出现高延时

用户量和课程数据量的持续增长,一个简单的分页列表就吃不消了?被PM疯狂输出了...

一开始我也一脸懵,3s+,一个分页查询不至于吧

本着经验分析了一下原因:

  • 数据量:主表关联表都在20w以下
  • sql复杂度:设计到3-5张表的左右关联和一个条件子查询,不算复杂
  • 索引:都设有组合or唯一索引

一通分析都没毛病,然后断点看了一下涉及到的sql时长。mapper进出用时3s+,那就还是这条sql的问题了;

继续打印sql复制到工具里直接查,发现用时极低:

此时想到pagehelper的分页是先查总条数count,再根据传参limit,可能问题出在count语句。再单独count主表条数,用时如下:

相差太大了,那问题就出在pageHelper的select count() 方法上了!

 

 

解决:

1.修改数据库的表引擎(InnoDB改为MyISAM),但是mysql版本超过8之后无法修改引擎为MyISAM类型,会报错

2.重写pagehelper的select count() 方法,在mapper接口中再加一个手动count总数的方法,不太优雅,但是可行

 

方法1简单,主要记录一下方法2。需要注意的是:pagehelper的版本需要在1.2.5或更高,才能支持重写该方法

过程如下:

在mapper接口里面再加上一个count方法,注意命名方式(在查询函数后面增加 _COUNT)和返回类型(必须为long),这样就覆盖了pagehelper的方法。

pagehelper会自动扫描,不需要进行其他的操作。

然后在xml里面写查询语句就可以了。

完结

posted @ 2022-04-15 15:34  空指针终结者  阅读(453)  评论(0)    收藏  举报