大家好，我是烤鴨：

????上上周末上線到凌晨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點，測試環境和本地環境都沒有復現，其中一個主要原因就是流量不夠，可能一兩個報錯信息會被忽略，導致排查問題難度加大。

再加上不是測試回歸的重點，以后針對上線的代碼還是要加強驗證。

總結

以上是生活随笔為你收集整理的上线到凌晨4点半 pagehelper的bug?的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。