填坑日志（20190926） PageHelper引发的慢SQL

场景描述

今天Leader从DB的慢SQL日志捞出来条分页SQL让我优化下，看完之后一脸懵逼，不对啊，这SQL我明明已经优化掉了，怎么还有？于是在预发环境打印了log，结果发现优化后的SQL确实执行了，但结果有点出乎我意料。执行的不是预期中的两条，而是四条。

分析过程

二话不说先把那两条SQL捞出来，格式很统一,两条SQL基本如下所示

select count(0) from (select xx from xxx) table_count

也就是在我原本的SQL外面又包了一层，然后重新执行了一次。
这么规则的sql，而且在代码中没有显示调用，很明显是分页插件，而我们只使用了PageHelper，于是检查了下配置，发现配置如下

pagehelper:
  helperDialect: mysql
  reasonable: true
  supportMethodsArguments: true  ###注意这一条

supportMethodsArguments在官方的解释如下：

• supportMethodsArguments：支持通过 Mapper 接口参数来传递分页参数，默认值false，分页插件会从查询方法的参数值中，自动根据上面 params 配置的字段中取值，查找到合适的值时就会自动分页。 使用方法可以参考测试代码中的 com.github.pagehelper.test.basic 包下的 ArgumentsMapTest 和 ArgumentsObjTest。
• params：为了支持startPage(Object params)方法，增加了该参数来配置参数映射，用于从对象中根据属性名取值， 可以配置 pageNum,pageSize,count,pageSizeZero,reasonable，不配置映射的用默认值， 默认值为pageNum=pageNum;pageSize=pageSize;count=countSql;reasonable=reasonable;pageSizeZero=pageSizeZero。

什么意思呢？大白话就是只要传递到Mapper的参数中包含了pageNum和pageSize它就会自动追加countSql进行分页处理。
元凶确认了，就是PageHelper自动生成的语句导致了慢SQL。
我已经自行处理了分页的count，并且注释掉了

PageHelper.startPage(query.getPageNum(),query.getPageSize());

没想到还是翻车了。

处理过程

最简单的做法莫过于设置supportMethodsArguments为false，但是考虑到这项目这么久了，还是不要动配置好，除非我准备检查所有分页并且手动开启分页。查了下API，发现这么个接口。

public static <E> Page<E> startPage(int pageNum, int pageSize, boolean count) { 
	return startPage(pageNum, pageSize, count, null, null); 
}

于是在取消掉之前的注释并改写为

PageHelper.startPage(query.getPageNum(),query.getPageSize(),false);

问题解决。

后记

查找资料的过程中了解到PageHelper其实是支持自动检测count语句的。

增加手写 count 查询支持

增加 countSuffix count 查询后缀配置参数，该参数是针对 PageInterceptor 配置的，默认值为 _COUNT。
分页插件会优先通过当前查询的 msId + countSuffix 查找手写的分页查询。
如果存在就使用手写的 count 查询，如果不存在，仍然使用之前的方式自动创建 count 查询。

什么意思呢？比如你的分页查询接口名为searchDetailByPage，只要将自己写的count语句命名为searchDetailByPage_COUNT，PageHelper就会使用我们自己写的count语句，不再自动生成。

后后记

嗯，我并没有修改原来的写法。
第一，我懒。
第二，那串代码不是我写的，让那家伙操心去吧。