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

完结