上线到凌晨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点，测试环境和本地环境都没有复现，其中一个主要原因就是流量不够，可能一两个报错信息会被忽略，导致排查问题难度加大。

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