快捷導(dǎo)航

Mybatis-plus分頁查詢不生效問題排查全過程

更新時間：2023年03月15日 11:24:09 作者：追尋上飛

最近寫分頁的時候,遇到了分頁無法正常發(fā)揮作用的問題,下面這篇文章主要給大家介紹了關(guān)于Mybatis-plus分頁查詢不生效問題排查的相關(guān)資料,文中通過實(shí)例代碼介紹的非常詳細(xì),需要的朋友可以參考下

一、問題描述

在查詢的時候，發(fā)現(xiàn)點(diǎn)擊后臺的分頁器數(shù)字，第2頁時候，數(shù)據(jù)還是和第1頁的一致。就看后臺的數(shù)據(jù)庫打印語句，如下所示。點(diǎn)擊第一頁和第二頁都是這個，limit后的參數(shù)只有一個，前期做過類似，點(diǎn)擊第二頁分頁的時候，語句是LIMIT ?，?

ON ap.id = a.project_id ORDER BY a.create_time DESC LIMIT ?

二、分析步驟

1.首先開始懷疑的是自己的分頁對象出現(xiàn)了問題，因?yàn)镸ySQL ORM框架使用了JPA框架遺留的代碼。將spring-data的分頁對象org.springframework.data.domain.Pageable轉(zhuǎn)成了mybatis-plus的分頁對象com.baomidou.mybatisplus.extension.plugins.pagination.Page<T>。

debug后，Page<T>的 current 和 size 都是存在且對應(yīng)前臺傳來的值。

2.接著懷疑是mybatis-plus的攔截器順序問題，因?yàn)轫?xiàng)目里寫了數(shù)據(jù)權(quán)限的攔截器，在研究數(shù)據(jù)權(quán)限攔截器的時候就看到有說攔截器添加順序會影響到SQL語句拼接的正確性。對比了正常的添加順序后，這部分也沒有問題。

   @Bean
    public MybatisPlusInterceptor mybatisPlusInterceptor() {
        MybatisPlusInterceptor interceptor = new MybatisPlusInterceptor();

        //添加數(shù)據(jù)權(quán)限處理器，注意順序，先數(shù)據(jù)權(quán)限再分頁
        MyDataPermissionInterceptor dataPermissionInterceptor = new MyDataPermissionInterceptor();
        // 添加自定義的數(shù)據(jù)權(quán)限處理器
        dataPermissionInterceptor.setDataPermissionHandler(new MyDataPermissionHandler());
        interceptor.addInnerInterceptor(dataPermissionInterceptor);

        interceptor.addInnerInterceptor(new PaginationInnerInterceptor());
        return interceptor;
    }

3.發(fā)現(xiàn)這兩部分都沒問題后，決定還是debug一下分頁攔截器。

重要的分頁SQL語句拼接函數(shù)如下。

DialectModel model = dialect.buildPaginationSql(buildSql, page.offset(), page.getSize());

進(jìn)入到里面，這里數(shù)據(jù)庫使用的MySQL。

public class MySqlDialect implements IDialect {

    @Override
    public DialectModel buildPaginationSql(String originalSql, long offset, long limit) {
        StringBuilder sql = new StringBuilder(originalSql).append(" LIMIT ").append(FIRST_MARK);
        if (offset != 0L) {
            sql.append(StringPool.COMMA).append(SECOND_MARK);
            return new DialectModel(sql.toString(), offset, limit).setConsumerChain();
        } else {
            return new DialectModel(sql.toString(), limit).setConsumer(true);
        }
    }
}

可以看到偏移量offset至關(guān)重要，決定了拼接的條件判斷。

又發(fā)現(xiàn)，offet的值和current相關(guān)，根據(jù)排查結(jié)果來看，current 是正常傳值的。

default long offset() {
        long current = this.getCurrent();
        return current <= 1L ? 0L : Math.max((current - 1L) * this.getSize(), 0L);
    }

因此到這里我們就會發(fā)現(xiàn)，是offset的真實(shí)值不正確。

當(dāng)后臺前端頁面?zhèn)鱽淼?code>current 是0時，offset等于0。

當(dāng)后臺前端頁面?zhèn)鱽淼?code>current 是1時，offset依舊等于0。

而回到拼接函數(shù)buildPaginationSql中，不等于0的時候才會有兩個參數(shù)的拼接。

至此，這個問題解決了，就是在對象轉(zhuǎn)換時，沒有對current的值進(jìn)行 + 1

三、解決方案

public class MyPage<T> extends Page<T> {

    /**
     * @Description: 將spring的分頁對象轉(zhuǎn)成Mybatis
     * @param pageable:
     * @return: null
     **/
    public MyPage(Pageable pageable) {
        this.setSize(pageable.getPageSize());
        this.setCurrent(pageable.getPageNumber() + 1);
    }
}