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里面写查询语句就可以了。
完结