大家好，我是烤鸭：
????上上周末上线到凌晨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点，测试环境和本地环境都没有复现，其中一个主要原因就是流量不够，可能一两个报错信息会被忽略，导致排查问题难度加大。
再加上不是测试回归的重点，以后针对上线的代码还是要加强验证。