上线到凌晨4点半 pagehelper的bug?

大家好，我是烤鸭：

上上周末上线到凌晨4点半，哭了，没想到问题竟然如此简单。最近又懒惰了，写了开头就一直放着了，今天终于补上。

问题日志

Error querying database. Cause: com.github.pagehelper.PageException: 被分页的语句已经包含了Top，不能再通过分页插件进行分页查询!

奇怪的是报错的语句并没有使用分页插件，只是一个简单的查询。

原因猜想

遇到问题第一时间回滚之后就好了，说明问题出现在这次提交。

跟pagehelper有关。

修改pom文件，更改 pagehelper 相关依赖，导致的问题。并不是。
修改了 pagehelper 的配置(配置类或者是yml)。也没有。
排除法，针对此次提交的代码进行部分上线。

问题复现

最后发现确实有个地方，写法是这样的。

由于项目拆分，把原来直接查库的地方改成了http调用，但是改写的人并没有关注业务逻辑，导致分页代码没有注释。(虽然注释了也不对，http改写的方法也没支持分页参数)

PageHelper.startPage(pageNum,pageSize);
//注释dao,改为http调用
//xxxDao.selectXxx();
xxxHttp.select();

就这样分页在当前的线程没有使用，当这个线程执行别的Sql 查询的时候，就会有问题，具体看下下面的源码分析。

源码分析

我们的数据库是SqlServer，Mysql和SqlServer的分页实现是不一样的。

下面的演示项目里分别模拟了不同的场景。

主要还是看下分页和SqlServer的实现源码。

分页插件整个核心代码是在 PageInterceptor 这个拦截器里。

执行 PageHelper.startPage(pageNum,pageSize); 时会将分页参数放到TheadLocal里。

PageMethod

public static <E> Page<E> startPage(int pageNum, int pageSize, boolean count, Boolean reasonable, Boolean pageSizeZero) {Page<E> page = new Page<E>(pageNum, pageSize, count);page.setReasonable(reasonable);page.setPageSizeZero(pageSizeZero);//当已经执行过orderBy的时候Page<E> oldPage = getLocalPage();if (oldPage != null && oldPage.isOrderByOnly()) {page.setOrderBy(oldPage.getOrderBy());}setLocalPage(page);return page;
}

finally里执行的AfterAll()代码就是在执行之后清空 ThreadLocal

public Object intercept(Invocation invocation) throws Throwable {try {Object[] args = invocation.getArgs();MappedStatement ms = (MappedStatement) args[0];Object parameter = args[1];RowBounds rowBounds = (RowBounds) args[2];ResultHandler resultHandler = (ResultHandler) args[3];Executor executor = (Executor) invocation.getTarget();CacheKey cacheKey;BoundSql boundSql;//由于逻辑关系，只会进入一次if (args.length == 4) {//4 个参数时boundSql = ms.getBoundSql(parameter);cacheKey = executor.createCacheKey(ms, parameter, rowBounds, boundSql);} else {//6 个参数时cacheKey = (CacheKey) args[4];boundSql = (BoundSql) args[5];}checkDialectExists();List resultList;//调用方法判断是否需要进行分页，如果不需要，直接返回结果if (!dialect.skip(ms, parameter, rowBounds)) {//判断是否需要进行 count 查询if (dialect.beforeCount(ms, parameter, rowBounds)) {//查询总数Long count = count(executor, ms, parameter, rowBounds, resultHandler, boundSql);//处理查询总数，返回 true 时继续分页查询，false 时直接返回if (!dialect.afterCount(count, parameter, rowBounds)) {//当查询总数为 0 时，直接返回空的结果return dialect.afterPage(new ArrayList(), parameter, rowBounds);}}resultList = ExecutorUtil.pageQuery(dialect, executor,ms, parameter, rowBounds, resultHandler, boundSql, cacheKey);} else {//rowBounds用参数值，不使用分页插件处理时，仍然支持默认的内存分页resultList = executor.query(ms, parameter, rowBounds, resultHandler, cacheKey, boundSql);}return dialect.afterPage(resultList, parameter, rowBounds);} finally {if(dialect != null){dialect.afterAll();}}
}

复现SqlServer报错信息：

Mysql的查询时也会报limit的错

SqlServerParser，报错语句出现在这

根据源码看到会先生成这样的语句，再根据传入的number和size进行替换

SELECT TOP 9223372036854775807 user_no FROM (SELECT ROW_NUMBER() OVER (ORDER BY RAND()) PAGE_ROW_NUMBER, user_no FROM (SELECT user_no FROM dbo.[user]) AS PAGE_TABLE_ALIAS) AS PAGE_TABLE_ALIAS WHERE PAGE_ROW_NUMBER > -9223372036854775808 ORDER BY PAGE_ROW_NUMBER

上面的源码是针对SqlServer分页时的，其实打个断点跟一下就行。

演示项目地址

https://gitee.com/fireduck_admin/pagehelper-maggie-demo

总结

为什么这个问题会折腾到4点，测试环境和本地环境都没有复现，其中一个主要原因就是流量不够，可能一两个报错信息会被忽略，导致排查问题难度加大。

再加上不是测试回归的重点，以后针对上线的代码还是要加强验证。